文章目录
技术方面
业务流程的建设
- 业务开发流程(从PRD到上线观测)IPD
- 代码开发流程规范
- 问题解决流程(ITR)
- 方便快捷的用户反馈建议渠道(可以参考聆听阿里云客户建议反馈平台,更加自助自由灵活的反馈渠道)
服务上线ready
k8s中服务上线后,最佳实践 就是等该准备的(数据库连接、缓存加载、预热等)处理完成后,再修改状态为ready
mq消费服务,启动前尽量也检查一下应有的状态是正常的在开始处理(在服务状态正常后再开始消费)
否则就容易出现服务状态异常、或者是数据状态异常的问题
举例:数据库网络偶尔会有报错,就直接开始处理了
服务设计
- 在线等可以扩缩容服务,一定要做无状态处理
- 如:日志中采用手动配置文件的机器名称,下游服务直接连接到本机获取文件(还要配置服务地址)
- 根据以往业务经验和数据,进行估算
- 服务保障等级划分
- 服务模块划分
- 服务资源CU合理分配(CPU Memory)
- 服务内存限制配置(运行时的内存设置)
日志文件处理打印
java异常有打印,其他语言
- 日志分级要做好,最简单的三层做好(info、warn、error)
- 不要多级try catch,一下一大片,看都没法看
- 打印的时候要把堆栈信息带上,不然只有日志没有堆栈怎么找问题
- 在线服务加requestId,异步消费任务加taskId,或者全局连贯的requestId
- 有elk日志收集的时候,做好限制日志文件大小,数量(不然就会导致磁盘占用高)
- 提高服务质量的时候,可是会根据报错信息进行告警处理的
服务下线处理
服务下线要做优雅关闭处理,以k8s举例
- 开始关闭前,取决于集群大小,在服务IP被其他上游依赖剔除掉再进行下一步关闭
- 服务内的数据库连接、mq消费
举例:mq消费服务有扩缩容,每天上线,没有处理优雅关闭,导致数据状态异常,最后队列堵塞
文件管理
目前文件管理基本都是对象存储实现的,只说这一种
- 做好业务——模块——功能的文件目录划分和管理
- 通过Tag标记业务数据存储周期,OSS可以根据Tag清理文件(实现降低成本)
- 如果业务方不做标记,其他人也管理不了这个东西,不清楚能不能删除,都要翻找代码查看,浪费额外时间
服务可观测性建设
- 系统指标收集(cpu、磁盘、memory、网络等)
- 日志收集处理
- 通过业务经验摸索,建立告警指标(不要去频繁什么都发,有些小问题分白天黑夜,最后导致都没有人去看。。。甚至告警群被屏蔽掉,只有业务负责人@才看,好的制度大家才会有默契的去遵循,推行才没有阻力)
- 和业务共同建立核心业务指,并对其数据做收集和告警系统(提前发现业务异常)
- 做业务前提前了解业务核心指标,上线发布后要持续观测一下有没有异常
合理的技术使用
- 有必要的情况下简化组件
- 比如我们用多语言开发,需要用到MQ,但是云服务MQ好多都是HTTP协议的,然后就被否掉了,最后采用了Redis当做MQ,现在又说要换回MQ(可能每天80w数据吧,这个量只能说是毫无压力,还只存储了ID)
- 对于业务中古老的,不稳定不靠谱的业务,要有计划的进行替换
网关流程
现在技术确实比较多,有些要了解的也不少
比如网关入口:
- 云SLB负载入口
- k8s中service设置
- 服务网关
- 有些服务里面还跑了nginx,链路好长
统一的语义化
变量:影响范围小,尽量和业务一致,业务变化有必要及时更新(举例:之前业务名称还进行互换,变量没有换,时间久了改代码就无语了)
常量:有公司全局意义的,一定要统一管理起来(我举个例子:就比如微信,有些叫做WX、weixin、WEIXIN、wechat,还互相转换,这。。。。。)在不同的系统里面,数据库表里千奇百怪,当其聚集在一起的时候就是一个头疼的问题,改进没有明显效益,只能任由起摆烂。
文档留存维护
- 目前的高并发系统基于mq消费设计,已经是事实了(各个消费流程与业务错综复杂,靠代码梳理很耗费时间精力)
- 业务之间的逻辑处理联系,没有文档,没有逻辑处理关系表示(接触新业务,做新功能设计的时候就懵了,只能去东看看西问问)
- 对于逻辑复杂的,尽量还是用流程图,图表表示出来的东西,
- 举例:某个平台有业务很挺复杂,然后不用图表示,就纯写了,一行话里面有要调用5个接口还有逻辑关系处理,还是国内TOP的公司
- 实在不行你把逻辑顺序、父子级列好,用ai kimi等生成uml图表示一下也行啊
- 文档更新与维护
- 我曾经接手一个项目,我一看README高兴坏了,写的真好,上手一试全是错误,已经跟实际脱离很远了
运用合适的开发工具
- 比如Copilot来提升效率
- 比如Apifox进行团队API管理,为每个API都留下测试用例,而不一定是要通过文档类进行传递
- 比如用一些云厂商数据库管理工具(批量修改后可以回滚,无锁变更等)
- 比如浏览器插件Automa,录制脚本处理重复的事情
如何快速学习
-
对于架构类的知识技术点,系统的从云厂商看起(网络规划、DNS解析、跨地域多活、服务治理、CDN、k8s实践、弹性部署、大数据、AI应用、客户实践、解决方案)这里推荐阿里云ACE白皮书,结合阿里云产品技术文档和火山云技术文档一起看,火山云文档写的会简练一些;阿里云很多产品产品都可以免费的试用体验。
-
阿里云ACE课程资料(认证根据自己需要进行考试)
-
火山云和阿里云文档自行搜索
-
推荐大家使用浏览器插件:笔记搜索(可以搜索语雀等其他平台,在浏览器搜索同时右侧搜索语雀等平台信息,里面也有很多优秀的创作者)
-
-
不是学习了云厂商就要用云厂商的东西,对于一些AI服务,小规模使用非实时在线后台任务,也许自建更具有性价比
-
保持空杯心态,对于新的技术和发展方向,起码做到了解,能够解决什么样的题,感兴趣或者业务需要的时候深入了解也不迟
-
只有对某一项技术了解什么,再遇到同类型的东西的时候,学习才会更快。只有学习的知识范围足够广阔,才能对对通用基础的知识有更加深刻的了解和体会
-
成长不一定是技术上的,对于做技术的我们来,如何做好产品、营销、管理、沟通、写作、统一也是一件很重要的事情,也很推荐大家在今天行业不景气去横向了解更多的人文相关内容,培养一些自己的兴趣爱好。
-
推荐大家看乔新亮的 CTO 成长复盘
-
樊登读书(学习更多多元化的知识)
-
-
对于学习和时间过的知识,及时的记录整理,合理的根据自己理解和主流的方案整理知识目录,根据自己学习知识范围和主流技术趋势进行更新整理,比如:
人文
很多目前也能看到问题,但是并没有很好的解决方案,但至少看到问题就是解决问题的关键
这个世界上有很多的问题,有足够丰富的阅历和经验,才知道在什么时机去解决什么样的问题
功夫须从事上磨
所处大环境行业公司
大环境不好不代表所有人都不好,有能力的还是会蒸蒸日上(总体不代表个体)
要看你自己处于该行业的水平,该换还是要换的
去一些薪资高的行业(比如金融、基金公司,交易软件,现在开的工资依旧还是很高)
周期在每个行业都是客观存在,投入回报周期都很长,要用长远的目光去看待事物的客观发展;
行业好的时候,可以看主流技术,快速提升实力取得更好的成绩。行情不好时候,发展自己的兴趣爱好,看一下其他的技术,或者是人文管理等自己感兴趣的东西。除去技术和工作,我还们有生活和自己的兴趣爱好。
去大公司还是小公司
有选择的余地,尽量去大一点公司
因为在里面会学到很多东西
比如:
- 需求是怎么来的(从客户访谈,数据埋点分析得来)
- 研发流程是什么样的(IPD、ITR)
- 是怎么增长的(通过埋点和数据分析工作,做AB测试)
- 业务解决方案,技术架构是怎么设计的
- 你只有见过别人用的什么,才能更快更好的学会(不然实践的经验很少)
- 公司的组织架构是怎么设计的
- 端到端的解决方案是怎么落地的
去现金牛业务还是创新业务
首先要认清自我的能力(如果你对这事情感兴趣,很有可能陷入信息茧房,搜索只会搜索自己想要的),或者咨询一些外部人士(比如付费咨询、社群、或者抖音等其他直播聊天软件,花点小钱冲个卡,上去聊聊天学习学习),来判断一下这些事情靠谱
- 公司领导肯定认为是靠谱的,不靠谱不会做
- 也许公司的氛围到了没有人能反驳领导的地步
- 也许是判断失误
什么情况下能做:
- 自己非常感兴趣
- 外部咨询或者了解都很好
- 有过工作经历或者经验,或者是带着已经成熟的业务到新公司去做
- 公司带有行业经验,能够复用老的经验
没有绝对把握怎么选择:
- 创新业务能不能持续推进,取决于公司领导的定力(比如阿里云,没有定力是绝对做不下去)
- 如果定力不高,有分吹草动就会砍掉(最终还是要转岗要去其他业务,或者被辞退掉)
- 公司有现金牛业务,新业务持续烧钱,业务分管就会很着急,开发进度等就会很急,肯定是要加班的
- 会很累还要加班,如果没有进行盈利,那么在你和其他业务部门对比,你做的更多情况下,大概率年终奖是不如他们高的
- 如果是新人肯定推荐去现金牛业务,新业务规范可能很潦草,而且也不稳定,等到真正有能力的时候去创新业务,成长收入两不误
价值观
公司的价值观,团队的价值观,团队氛围,合理的晋升制度和渠道,对鼓舞士气有莫大的帮助。
我曾经公司招聘讲师,开展过技术培训。大致套路就是那样,还找开发区面试学生,然后回复他们能力不行,可以来贷款培训,对于这种事情和套路,正常工作员工走的很快,大家价值观不合。
又或者公司为了快速拉高GMV,做了损害用户利益的事情,违背了公司自己的价值观和初心,大家价值观能合吗?
又或者说,口口声声为了员工福利,借修改年假制度克扣年假,员工能和公司站在一起吗?
又或者做了这些事情,招聘的时候要求HR找价值观正的候选人,那什么是价值观正?我们连长期主义,正确规规矩矩的做事情都做不到。
我想没有人会说自己是坏蛋,做过什么坏事,说自己做好事的时候希望也想明白,不一定要说,因为你做违反自己说过的话、价值观的时候,在别人也眼里什么也是。
只有频繁地重复输出,坚持言传身教,使命和愿景才能从墙上走下来——公司的价值观也一样
公司的制度规范
调整公司政策降低福利的时候,在行业下行还是要谨慎,不要使用联合组合拳,对士气打压。
大家都希望每天好好一点点,那如果直接降低损害自己的利益,可能很多人就不愿意额外奉献了。
一个组织就如同一个人,如何让这个组织有格局,并且能快速学习、持续迭代,是管理者一个重要的能力。迭代,就意味着前面有不完美的地方,在全局视角下具备纠错能力,用更短的周期、更快的速度持续完善,这样组织能力也会随着时间,不断登上新的台阶。——乔新亮
团队的氛围
- 我经历过很多时候大家比较热情,也都会耐心解答,寻找解决方案
- 我也见过去问业务问题,就是一句话自己看(如果自己离职做项目交接的时候,你一句自己看?公司答应么?)
- 技术的东西自己看能够理解,业务没有留存文档还要自己去看代码(多个系统之间的异步处理),我感觉是浪费时间了
- 对于不熟悉这个技术的同学,我想还是多一些耐心,告诉别人有没有快速学习的经验和捷径,给别人讲的同时也是自己学习的过程。也可以整理成文档分享给大家。
- 我觉得去看有些博文留言,或者issus,很多都会耐心的解答(大家还是陌生人,依然会乐于帮助其他人)
- 职场上关于沟通的一些思考
- 对待公司内外合作机会,拿出应该有的工作态度,负好自己的责任;事情和我不相干,那么自己也知道谁熟悉能不能去推荐一下,给予一些帮助
- 曾经也遇到过业务部门变动,全部门接手新的业务,找一个线上的测试账号,才问了两个人皮球就踢闭环了。
- 我曾经还遇到因为需求流程没有管理起来,需求变更后没有通知到,最后开会快上线了才知道
- 我有点抱怨的情绪,还告诉我需求不明白随时来问我,需求变更没有通知你不在我职责范围内。——听起来有点嘲讽人的感觉。
- 在公司内做事情,把事情做好是一切的基础,也是自己和公司存在的价值,很多时候还是要多发挥一下情商。
- 在公司内做好自己的口碑,把该付的责任负起来。可能是这事情跟我没关系,但是我知道怎么做,或者知道找谁做,那么就推荐一下。问你的人比你掌握的信息还少,还无知(真的不知道)。你所做的事情,你的态度,其他同事都看在眼里,做得好咱们就不说,做的不好一定会有议论!!!喜欢八卦的人远比你想的多。
- 如果你遇到了公司不合理的制度,不和氛围的团队,我想还是要找到一个适合自己的环境,找到自己热爱做的事情,能够进入心流状态的事情。多从自己的成长考虑,我们可以为公司负责(比如对外的形象,处理问题的态度),为团队负责(分享一些自己工作技术经验),为业务负责(对业务留存文档,紧急修复业务问题),更要为为自己负责,因为人人都是产品经理。人人都有掌握自己发展和命运的权利。