软件行业经验

技术方面

业务流程的建设

1. 业务开发流程（从PRD到上线观测）IPD
2. 代码开发流程规范
3. 问题解决流程（ITR）
4. 方便快捷的用户反馈建议渠道（可以参考聆听阿里云客户建议反馈平台，更加自助自由灵活的反馈渠道）

服务上线ready

k8s中服务上线后，最佳实践 就是等该准备的（数据库连接、缓存加载、预热等）处理完成后，再修改状态为ready

mq消费服务，启动前尽量也检查一下应有的状态是正常的在开始处理（在服务状态正常后再开始消费）

否则就容易出现服务状态异常、或者是数据状态异常的问题

举例：数据库网络偶尔会有报错，就直接开始处理了

服务设计

1. 在线等可以扩缩容服务，一定要做无状态处理
   1. 如：日志中采用手动配置文件的机器名称，下游服务直接连接到本机获取文件（还要配置服务地址）
2. 根据以往业务经验和数据，进行估算
3. 服务保障等级划分
4. 服务模块划分
5. 服务资源CU合理分配（CPU Memory）
6. 服务内存限制配置（运行时的内存设置）

日志文件处理打印

java异常有打印，其他语言

1. 日志分级要做好，最简单的三层做好（info、warn、error）
2. 不要多级try catch，一下一大片，看都没法看
3. 打印的时候要把堆栈信息带上，不然只有日志没有堆栈怎么找问题
4. 在线服务加requestId，异步消费任务加taskId，或者全局连贯的requestId
5. 有elk日志收集的时候，做好限制日志文件大小，数量（不然就会导致磁盘占用高）
6. 提高服务质量的时候，可是会根据报错信息进行告警处理的

服务下线处理

服务下线要做优雅关闭处理，以k8s举例

1. 开始关闭前，取决于集群大小，在服务IP被其他上游依赖剔除掉再进行下一步关闭
2. 服务内的数据库连接、mq消费

举例：mq消费服务有扩缩容，每天上线，没有处理优雅关闭，导致数据状态异常，最后队列堵塞

文件管理

目前文件管理基本都是对象存储实现的，只说这一种

1. 做好业务——模块——功能的文件目录划分和管理
2. 通过Tag标记业务数据存储周期，OSS可以根据Tag清理文件（实现降低成本）
   1. 如果业务方不做标记，其他人也管理不了这个东西，不清楚能不能删除，都要翻找代码查看，浪费额外时间

服务可观测性建设

1. 系统指标收集（cpu、磁盘、memory、网络等）
2. 日志收集处理
3. 通过业务经验摸索，建立告警指标（不要去频繁什么都发，有些小问题分白天黑夜，最后导致都没有人去看。。。甚至告警群被屏蔽掉，只有业务负责人@才看，好的制度大家才会有默契的去遵循，推行才没有阻力）
4. 和业务共同建立核心业务指，并对其数据做收集和告警系统（提前发现业务异常）
   1. 做业务前提前了解业务核心指标，上线发布后要持续观测一下有没有异常

合理的技术使用

1. 有必要的情况下简化组件
2. 比如我们用多语言开发，需要用到MQ，但是云服务MQ好多都是HTTP协议的，然后就被否掉了，最后采用了Redis当做MQ，现在又说要换回MQ（可能每天80w数据吧，这个量只能说是毫无压力，还只存储了ID）
3. 对于业务中古老的，不稳定不靠谱的业务，要有计划的进行替换

网关流程

现在技术确实比较多，有些要了解的也不少

比如网关入口：

1. 云SLB负载入口
2. k8s中service设置
3. 服务网关
4. 有些服务里面还跑了nginx，链路好长

统一的语义化

变量：影响范围小，尽量和业务一致，业务变化有必要及时更新（举例：之前业务名称还进行互换，变量没有换，时间久了改代码就无语了）

常量：有公司全局意义的，一定要统一管理起来（我举个例子：就比如微信，有些叫做WX、weixin、WEIXIN、wechat，还互相转换，这。。。。。）在不同的系统里面，数据库表里千奇百怪，当其聚集在一起的时候就是一个头疼的问题，改进没有明显效益，只能任由起摆烂。

文档留存维护

1. 目前的高并发系统基于mq消费设计，已经是事实了（各个消费流程与业务错综复杂，靠代码梳理很耗费时间精力）
2. 业务之间的逻辑处理联系，没有文档，没有逻辑处理关系表示（接触新业务，做新功能设计的时候就懵了，只能去东看看西问问）
3. 对于逻辑复杂的，尽量还是用流程图，图表表示出来的东西，
   1. 举例：某个平台有业务很挺复杂，然后不用图表示，就纯写了，一行话里面有要调用5个接口还有逻辑关系处理，还是国内TOP的公司
   2. 实在不行你把逻辑顺序、父子级列好，用ai kimi等生成uml图表示一下也行啊
4. 文档更新与维护
   1. 我曾经接手一个项目，我一看README高兴坏了，写的真好，上手一试全是错误，已经跟实际脱离很远了

运用合适的开发工具

1. 比如Copilot来提升效率
2. 比如Apifox进行团队API管理，为每个API都留下测试用例，而不一定是要通过文档类进行传递
3. 比如用一些云厂商数据库管理工具（批量修改后可以回滚，无锁变更等）
4. 比如浏览器插件Automa，录制脚本处理重复的事情

如何快速学习

1. 对于架构类的知识技术点，系统的从云厂商看起（网络规划、DNS解析、跨地域多活、服务治理、CDN、k8s实践、弹性部署、大数据、AI应用、客户实践、解决方案）这里推荐阿里云ACE白皮书，结合阿里云产品技术文档和火山云技术文档一起看，火山云文档写的会简练一些；阿里云很多产品产品都可以免费的试用体验。

   1. 阿里云ACE课程资料（认证根据自己需要进行考试）

   2. 火山云和阿里云文档自行搜索

   3. 推荐大家使用浏览器插件：笔记搜索（可以搜索语雀等其他平台，在浏览器搜索同时右侧搜索语雀等平台信息，里面也有很多优秀的创作者）

      阿里云云计算架构师 ACE 认证_阿里云认证_阿里云培训中心-阿里云

2. 不是学习了云厂商就要用云厂商的东西，对于一些AI服务，小规模使用非实时在线后台任务，也许自建更具有性价比

3. 保持空杯心态，对于新的技术和发展方向，起码做到了解，能够解决什么样的题，感兴趣或者业务需要的时候深入了解也不迟

4. 只有对某一项技术了解什么，再遇到同类型的东西的时候，学习才会更快。只有学习的知识范围足够广阔，才能对对通用基础的知识有更加深刻的了解和体会

5. 成长不一定是技术上的，对于做技术的我们来，如何做好产品、营销、管理、沟通、写作、统一也是一件很重要的事情，也很推荐大家在今天行业不景气去横向了解更多的人文相关内容，培养一些自己的兴趣爱好。

   1. 推荐大家看乔新亮的 CTO 成长复盘

   2. 樊登读书（学习更多多元化的知识）

      乔新亮的CTO成长复盘_管理_架构_CTO_技术总监_求职_成长_年薪_团队-极客时间

6. 对于学习和时间过的知识，及时的记录整理，合理的根据自己理解和主流的方案整理知识目录，根据自己学习知识范围和主流技术趋势进行更新整理，比如：

   wxya

人文

很多目前也能看到问题，但是并没有很好的解决方案，但至少看到问题就是解决问题的关键

这个世界上有很多的问题，有足够丰富的阅历和经验，才知道在什么时机去解决什么样的问题

功夫须从事上磨

所处大环境行业公司

公司分析

行业观

大环境不好不代表所有人都不好，有能力的还是会蒸蒸日上（总体不代表个体）

要看你自己处于该行业的水平，该换还是要换的

去一些薪资高的行业（比如金融、基金公司，交易软件，现在开的工资依旧还是很高）

周期在每个行业都是客观存在，投入回报周期都很长，要用长远的目光去看待事物的客观发展；

行业好的时候，可以看主流技术，快速提升实力取得更好的成绩。行情不好时候，发展自己的兴趣爱好，看一下其他的技术，或者是人文管理等自己感兴趣的东西。除去技术和工作，我还们有生活和自己的兴趣爱好。

去大公司还是小公司

有选择的余地，尽量去大一点公司

因为在里面会学到很多东西

比如：

1. 需求是怎么来的（从客户访谈，数据埋点分析得来）
2. 研发流程是什么样的（IPD、ITR）
3. 是怎么增长的（通过埋点和数据分析工作，做AB测试）
4. 业务解决方案，技术架构是怎么设计的
   1. 你只有见过别人用的什么，才能更快更好的学会（不然实践的经验很少）
5. 公司的组织架构是怎么设计的
6. 端到端的解决方案是怎么落地的

去现金牛业务还是创新业务

业务结构分析-波士顿矩阵分析法

首先要认清自我的能力（如果你对这事情感兴趣，很有可能陷入信息茧房，搜索只会搜索自己想要的），或者咨询一些外部人士（比如付费咨询、社群、或者抖音等其他直播聊天软件，花点小钱冲个卡，上去聊聊天学习学习），来判断一下这些事情靠谱

1. 公司领导肯定认为是靠谱的，不靠谱不会做
2. 也许公司的氛围到了没有人能反驳领导的地步
3. 也许是判断失误

什么情况下能做：

1. 自己非常感兴趣
2. 外部咨询或者了解都很好
3. 有过工作经历或者经验，或者是带着已经成熟的业务到新公司去做
4. 公司带有行业经验，能够复用老的经验

没有绝对把握怎么选择：

1. 创新业务能不能持续推进，取决于公司领导的定力（比如阿里云，没有定力是绝对做不下去）
2. 如果定力不高，有分吹草动就会砍掉（最终还是要转岗要去其他业务，或者被辞退掉）
3. 公司有现金牛业务，新业务持续烧钱，业务分管就会很着急，开发进度等就会很急，肯定是要加班的
4. 会很累还要加班，如果没有进行盈利，那么在你和其他业务部门对比，你做的更多情况下，大概率年终奖是不如他们高的
5. 如果是新人肯定推荐去现金牛业务，新业务规范可能很潦草，而且也不稳定，等到真正有能力的时候去创新业务，成长收入两不误

价值观

公司的价值观，团队的价值观，团队氛围，合理的晋升制度和渠道，对鼓舞士气有莫大的帮助。

我曾经公司招聘讲师，开展过技术培训。大致套路就是那样，还找开发区面试学生，然后回复他们能力不行，可以来贷款培训，对于这种事情和套路，正常工作员工走的很快，大家价值观不合。

又或者公司为了快速拉高GMV，做了损害用户利益的事情，违背了公司自己的价值观和初心，大家价值观能合吗？

又或者说，口口声声为了员工福利，借修改年假制度克扣年假，员工能和公司站在一起吗？

又或者做了这些事情，招聘的时候要求HR找价值观正的候选人，那什么是价值观正？我们连长期主义，正确规规矩矩的做事情都做不到。

我想没有人会说自己是坏蛋，做过什么坏事，说自己做好事的时候希望也想明白，不一定要说，因为你做违反自己说过的话、价值观的时候，在别人也眼里什么也是。

只有频繁地重复输出，坚持言传身教，使命和愿景才能从墙上走下来——公司的价值观也一样

公司的制度规范

调整公司政策降低福利的时候，在行业下行还是要谨慎，不要使用联合组合拳，对士气打压。

大家都希望每天好好一点点，那如果直接降低损害自己的利益，可能很多人就不愿意额外奉献了。

一个组织就如同一个人，如何让这个组织有格局，并且能快速学习、持续迭代，是管理者一个重要的能力。迭代，就意味着前面有不完美的地方，在全局视角下具备纠错能力，用更短的周期、更快的速度持续完善，这样组织能力也会随着时间，不断登上新的台阶。——乔新亮

团队的氛围

1. 我经历过很多时候大家比较热情，也都会耐心解答，寻找解决方案
2. 我也见过去问业务问题，就是一句话自己看（如果自己离职做项目交接的时候，你一句自己看？公司答应么？）
   1. 技术的东西自己看能够理解，业务没有留存文档还要自己去看代码（多个系统之间的异步处理），我感觉是浪费时间了
   2. 对于不熟悉这个技术的同学，我想还是多一些耐心，告诉别人有没有快速学习的经验和捷径，给别人讲的同时也是自己学习的过程。也可以整理成文档分享给大家。
   3. 我觉得去看有些博文留言，或者issus，很多都会耐心的解答（大家还是陌生人，依然会乐于帮助其他人）
   4. 职场上关于沟通的一些思考
3. 对待公司内外合作机会，拿出应该有的工作态度，负好自己的责任；事情和我不相干，那么自己也知道谁熟悉能不能去推荐一下，给予一些帮助
   1. 曾经也遇到过业务部门变动，全部门接手新的业务，找一个线上的测试账号，才问了两个人皮球就踢闭环了。
4. 我曾经还遇到因为需求流程没有管理起来，需求变更后没有通知到，最后开会快上线了才知道
   1. 我有点抱怨的情绪，还告诉我需求不明白随时来问我，需求变更没有通知你不在我职责范围内。——听起来有点嘲讽人的感觉。
   2. 在公司内做事情，把事情做好是一切的基础，也是自己和公司存在的价值，很多时候还是要多发挥一下情商。
5. 在公司内做好自己的口碑，把该付的责任负起来。可能是这事情跟我没关系，但是我知道怎么做，或者知道找谁做，那么就推荐一下。问你的人比你掌握的信息还少，还无知（真的不知道）。你所做的事情，你的态度，其他同事都看在眼里，做得好咱们就不说，做的不好一定会有议论！！！喜欢八卦的人远比你想的多。
6. 如果你遇到了公司不合理的制度，不和氛围的团队，我想还是要找到一个适合自己的环境，找到自己热爱做的事情，能够进入心流状态的事情。多从自己的成长考虑，我们可以为公司负责（比如对外的形象，处理问题的态度），为团队负责（分享一些自己工作技术经验），为业务负责（对业务留存文档，紧急修复业务问题），更要为为自己负责，因为人人都是产品经理。人人都有掌握自己发展和命运的权利。