🗒️软件行业经验

技术方面

业务流程的建设

1. 业务开发流程（从PRD到上线观测）IPD

2. 代码开发流程规范

3. 问题解决流程（ITR）

4. 方便快捷的用户反馈建议渠道（可以参考聆听阿里云客户建议反馈平台，更加自助自由灵活的反馈渠道）

服务上线ready

服务设计

1. 在线等可以扩缩容服务，一定要做无状态处理
1. 如：日志中采用手动配置文件的机器名称，下游服务直接连接到本机获取文件（还要配置服务地址）

2. 合理的服务拆分
1. 如果同一个业务功能流程，在不同的系统之间流程，碰到其他服务网络问题、异常重启、逻辑问题，最终会导致数据的不一致。这时候就需要额外处理了（比如用mq、定时任务扫表来修正或者保证链路数据传递的可靠性）

3. 根据以往业务经验和数据，进行估算（通过业务埋点等方式进行统计）

4. 服务保障等级划分

5. 服务模块划分

6. 服务资源CU合理分配（CPU Memory）

7. 容器内业务服务的内存限制配置（运行时的内存设置）

日志文件处理打印

1. 日志分级要做好，最简单的三层做好（info、warn、error）

2. 外部、内部、三方 API 调用失败异常问题打印

3. 不要多级try catch，一下一大片，看都没法看

4. 参数内有文件（base64的或者其他形式的）的，要忽略掉该参数

5. 打印的时候要把堆栈信息带上，不然只有日志没有堆栈怎么找问题

6. 日志链路的全局ID ，异步消费任务的taskId（requestId、tid、traceId、trackid都一样的）

7. 有elk日志收集的时候，做好限制日志文件大小，数量（不然就会导致磁盘占用高）

8. 提高服务质量的时候，可是会根据报错信息进行告警处理的

预发布环境管理

1. dev pre prod发布分支收敛，不要可以任意发布来源分支代码（环境代码变更异常，浪费时间）

2. 如果是微服务，多人协作协同开发，技术实力足够的情况下，最好的方式还是用全链路灰度

3. 服务发布可以采用灰度，发布期间注意观测业务指标

服务下线处理

1. 开始关闭前，取决于集群大小，在服务IP被其他上游依赖剔除掉再进行下一步关闭

2. 服务内的数据库连接、mq消费等

服务发布管理

1. 整体功能测试环境验收通过，准备发布打版本（不然影响后面人工作）

2. 发布的影响范围预估

3. 发布的服务依赖顺序

4. 有没有对老用户做兼容处理

5. 发布策略选择

6. 发布时间确定（大部分情况下没有这么复杂）

文件管理

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，链路好长

统一的语义化

文档留存维护

1. 目前的高并发系统基于mq消费设计，已经是事实了（各个消费流程与业务错综复杂，靠代码梳理很耗费时间精力）

2. 业务之间的逻辑处理联系，没有文档，没有逻辑处理关系表示（接触新业务，做新功能设计的时候就懵了，只能去东看看西问问）

3. 对于逻辑复杂的，尽量还是用流程图，图表表示出来的东西，
1. 举例：某个平台有业务很挺复杂，然后不用图表示，就纯写了，一行话里面有要调用5个接口还有逻辑来回调用，等待重试关系处理，还是国内TOP的公司
2. 实在不行你把逻辑顺序、父子级列好，用ai kimi等生成uml图表示一下也行啊

4. 文档更新与维护
1. 我曾经接手一个项目，我一看README高兴坏了，写的真好，上手一试全是错误，已经跟实际脱离很远了

5. 推荐新项目包含文档内容
1. 开发维护文档（本地运行环境配置，核心业务调试流程方法，测试环境，业务发布流程，服务观测方法）
2. 数据库以及常用表
3. 立项说明（项目背景，解决问题，成果）
4. 主服务业务流程图、服务依赖流程图、框架技术设计、数据流程图
5. 业务侧常见问题FAQ——通过沉淀FAQ可以即可LLM RAG做智能客服

运用合适的开发工具

1. 比如Copilot来提升效率

2. 比如Apifox进行团队API管理，为每个API都留下测试用例，而不一定是要通过文档类进行传递

3. 比如用一些云厂商数据库管理工具（批量修改后可以回滚、无锁变更（增加索引不锁表）、不开启性能洞察也有一个 10 秒 sql 分析，可以快速定位解决问题等）比如阿里云DMS就有这个功能

4. 比如浏览器插件Automa，录制脚本处理重复的事情

如何快速学习

1. 对于架构类的知识技术点，系统的从云厂商看起（网络规划、DNS解析、跨地域多活、服务治理、CDN、k8s实践、弹性部署、大数据、AI应用、客户实践、解决方案）这里推荐阿里云ACE白皮书，结合阿里云产品技术文档和火山云技术文档一起看，火山云文档写的会简练一些；阿里云很多产品产品都可以免费的试用体验。
1. 阿里云ACE课程资料（认证根据自己需要进行考试）
2. 火山云和阿里云文档自行搜索
3. 推荐大家使用浏览器插件：笔记搜索（可以搜索语雀等其他平台，在浏览器搜索同时右侧搜索语雀等平台信息，里面也有很多优秀的创作者）

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

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

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

5. 深入细节，总结浓缩简化（深入浅出）

6. 成长不一定是技术上的，对于做技术的我们来，如何做好产品、营销、管理、沟通、写作、统一也是一件很重要的事情，也很推荐大家在今天行业不景气去横向了解更多的人文相关内容，培养一些自己的兴趣爱好。
1. 乔新亮的 CTO 成长复盘
2. 樊登读书（学习更多多元化的知识）
3. ByteByteGo（微信公众号、网站、YouTube）
4. PPHC高并发哲学原理——本书的目标是在作者有限的认知范围内，讨论一下高并发问题背后隐藏的一个哲学原理——找出单点，进行拆分。
5. 深入架构原理和实践——这几年互联网基础设施技术出现了很大的更新迭代，比如容器技术（Container、Kubernetes）、服务网格（ServiceMesh）、无服务器（Serverless）、高性能网络（DPDK、XDP） 等等，我对这些技术有一些浅薄的见解和实践，但也远没达到深刻理解的境界，我尝试使用 费曼学习法 把这些东西体系化地总结输出。一方面是加深自我的学习认识，另一方面也希望这些输出对其他人有所帮助。
6. SDN软件定义网络
7. 微服务架构设计
8. Factory12要素
9. 凤凰架构

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

人文

所处大环境行业公司

去大公司还是小公司

1. 需求是怎么来的（从客户访谈，数据埋点分析得来）

2. 研发流程是什么样的（IPD、ITR）

3. 是怎么增长的（通过埋点和数据分析工作，做AB测试）

4. 业务解决方案，技术架构是怎么设计的
1. 你只有见过别人用的什么，才能更快更好的学会（不然实践的经验很少）

5. 公司的组织架构是怎么设计的

6. 端到端的解决方案是怎么落地的

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

1. 公司领导肯定认为是靠谱的，不靠谱不会做

2. 也许公司的氛围到了没有人能反驳领导的地步

3. 也许是判断失误

1. 自己非常感兴趣

2. 外部咨询或者了解都很好

3. 有过工作经历或者经验，或者是带着已经成熟的业务到新公司去做

4. 公司带有行业经验，能够复用老的经验

1. 创新业务能不能持续推进，取决于公司领导的定力（比如阿里云，没有定力是绝对做不下去）

2. 如果定力不高，有分吹草动就会砍掉（最终还是要转岗要去其他业务，或者被辞退掉）

3. 公司有现金牛业务，新业务持续烧钱，业务分管就会很着急，开发进度等就会很急，肯定是要加班的
1. 会很累还要加班，如果没有进行盈利，那么在你和其他业务部门对比，你做的更多情况下，大概率年终奖是不如他们高的

4. 如果是新人肯定推荐去现金牛业务，新业务规范可能很潦草，而且也不稳定，等到真正有能力的时候去创新业务，成长收入两不误

价值观

公司的制度规范

团队的氛围

1. 我经历过很多时候大家比较热情，也都会耐心解答，寻找解决方案

2. 我也见过去问业务问题，就是一句话自己看（如果自己离职做项目交接的时候，你一句自己看？公司答应么？）
1. 技术的东西自己看能够理解，业务没有留存文档还要自己去看代码（多个系统之间的异步处理），我感觉是浪费时间了
2. 对于不熟悉这个技术的同学，我想还是多一些耐心，告诉别人有没有快速学习的经验和捷径，给别人讲的同时也是自己学习的过程。也可以整理成文档分享给大家。
3. 我觉得去看有些博文留言，或者issus，很多都会耐心的解答（大家还是陌生人，依然会乐于帮助其他人）
4. 职场上关于沟通的一些思考

3. 对待公司内外合作机会，拿出应该有的工作态度，负好自己的责任；事情和我不相干，那么自己也知道谁熟悉能不能去推荐一下，给予一些帮助
1. 曾经也遇到过业务部门变动，全部门接手新的业务，找一个线上的测试账号，才问了两个人皮球就踢闭环了。

4. 我曾经还遇到因为需求流程没有管理起来，需求变更后没有通知到，最后开会快上线了才知道
1. 我有点抱怨的情绪，还告诉我需求不明白随时来问我，需求变更没有通知你不在我职责范围内。——听起来有点嘲讽人的感觉。
2. 在公司内做事情，把事情做好是一切的基础，也是自己和公司存在的价值，很多时候还是要多发挥一下情商。

5. 在公司内做好自己的口碑，把该付的责任负起来。可能是这事情跟我没关系，但是我知道怎么做，或者知道找谁做，那么就推荐一下。问你的人比你掌握的信息还少，还无知（真的不知道）。你所做的事情，你的态度，其他同事都看在眼里，做得好咱们就不说，做的不好一定会有议论！！！喜欢八卦的人远比你想的多。

6. 如果你遇到了公司不合理的制度，不和氛围的团队，我想还是要找到一个适合自己的环境，找到自己热爱做的事情，能够进入心流状态的事情。多从自己的成长考虑，我们可以为公司负责（比如对外的形象，处理问题的态度），为团队负责（分享一些自己工作技术经验），为业务负责（对业务留存文档，紧急修复业务问题），更要为为自己负责，因为人人都是产品经理。人人都有掌握自己发展和命运的权利。