一个INFRA工程师的思考
个人的思考方面：
感觉一个TL关注的不应该是单纯哪部分做个灾备，哪部分做个备份之类的东西，更关注的应该是software engineer的大的衡量标准。实际上TL要考虑的可能是目前有哪些东西不能动？这些部分能不能筛查出来？我们究竟是多灵活？在这个过程当中我觉得很多监控的东西要做起来
software engineer要多于单纯的code complete，其中metain的东西比较多，所以实际上代码这块我们要考虑的不单纯是研发，还要考虑matain的问题，所以我建议INFRA这部分在review的时候要加一个matain的成员，matain的成员要考虑的事情就很多了。这里代码review还需要考虑一点，该谁的代码，就要让谁review，这点需要注意，不是光改完了就完了，一定要通知到个人。
还有一个事情，就是代码的研发者要对代码的用户直接负责，代码使用者的组织需要有个人专门管理由依赖引起的问题。当代码的研发者进行了版本升级或者相关的改动时，需要通知到用户做评估，可能有人问，我怎么直到谁用了我的代码呢？bazel管理的代码deps有直接的依赖，可以非常清楚的获知。
当我们做决定的时候我们考虑什么？
- 时间和变化
- 代码的影响范围，这个影响范围是个抽象的东西，我觉得不妨考虑代码的声明周期，
- 代码的改变承诺，
- Hyrum’s Law：我认为我们应当为承诺型，即C++的行为，我们承诺我们做到什么，其它的不保证，用错了是UB
- With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.
- 规模和效率
- Your organization’s codebase is sustainable when you are able to change all of the things that you ought to change, safely, and can do so for the life of your codebase。换言之，我们应该将任何固定依赖或者说不可替代的东西替换为可替代物
- 我们应当能够类似衡量硬件资源那样子，衡量人力和具体的涉及到workflow都是不可持久的both in terms of human time involvement and the compute resources that power your development workflow. 实际上我们就是在衡量codebase
- 问题来了，如何衡量一个策略是不是糟糕的呢？看这个策略对单个工程师的影响，并考虑当组织扩大十倍的时候，是不是会导致消耗扩大十倍
- 一个兼容的rule为infrastructure teams must do the work to move their internal users to new versions themselves or do the update in place, in backward-compatible fashion.
- If a product experiences outages or other problems as a result of infrastructure changes, but the issue wasn’t surfaced by tests in our Continuous Integration (CI) system, it is not the fault of the infrastructure change. 实际上我们的CI应该能够检测到这种错误，换言之If you liked it, you should have put a CI test on it
- Trade-offs和代价
因此，我这段时间做了什么呢？从多个方面来考虑：
对设备的管理：
- 编写阿里云ack集群的机器的setup脚本，实现扩容的自动化
- 根据机器的上任务的运行时长，并发效率和我们任务的新建数量，计算出所需要的机器数量
- 针对仿真集群，编写自动cordon脚本
对内部环境的管理：
- setup & 维护 buildfarm环境，从1.12 => 1.15并启用nginx同时使用主备buildfarm环境应对公司内部任务量代码量的激增，目前看起来效果显著。
- 围绕gitlab的workflow优化：gitlab-webhook & margebot流程优化与拆分，margebot优化了4/5s
- 建立CI/CD的告警监控机制
- KMS
排查各种cratical problem：
- 定位仿真性能问题，并给出对应的总结和处理手段，总结4,5次。
- 定位内存泄漏，coredump等问题，累计两次。
- 排查并解决基础架构业务过慢问题，gitlab+arm机器慢，2次
唉，尴尬
