前段时间，我看到一个开源项目团队在抱怨有用户火急火燎的催他们帮忙解决问题。这个用户在微信群里，GitHub issue 上到处留言，就是那种“在线等，挺急的”。这在开源社区一般被认为是不太礼貌的行为。可看着标题里的“急”和感叹号，我很能理解他的心情，毕竟我是个善良的老系统工程师。
回想以前在一线处理生产系统故障的岁月，那种压力真的可以轻易就让新手着急忙慌的。类似的情况也绝非个例，在 Milvus 社区我们也时不时会碰到一次。因此，我想给新手系统管理员一些成长的建议，希望能帮到大家成为出色的系统管理员。
由于大家所使用的计算机系统，基础软件技术栈，以及面对的应用场景都不同，我没法在这里给出具体的诸如 Kubernetes 和 PostgreSQL 如何学习这样的建议。以下的建议主要针对一些软技能，比如系统管理员看问题的角度、处理问题的方法等。
系统管理员 (system administrator)，也被称为系统工程师 (system engineer)。很多人简单粗暴的把软件相关的技术人员分成开发、测试、运维三大类。并且更加粗暴的给出一个偏见：能力强的去做开发，稍差一点去做测试，剩下的去搞运维。
这个愚蠢的说法所传甚广，实际上不同的角色需要的能力大不相同。国外是如何看待系统管理员这个角色的？这张来自 Reddit 的图片，可以让大家有个感性的认识。
为什么系统管理员会给人一种牛哄哄的感觉呢？
开发人员的目标是解决问题，测试人员的目标是发现问题。系统管理员的目标是尽全力保证系统的正常运行。但问题在于，任何基础软件在任何时间点上都有一堆 bug（已知的，未知的，有解的，无解的）。因此系统管理员需要基于不确定性来构建确定性。
第一个建议：不要迷信任何基础软件。哪怕再主流、再好用的基础软件，有一天也会让你焦头烂额的在线上解生产问题。当然，这条建议并不是要让你藐视权威，而是说系统管理员需要保留一分审慎。任何软件系统都有其能力的边界。明白边界在哪里，可以避免很多不必要的问题。
第二个建议：学习一个软件系统的重要一步是尝试把它搞挂。系统管理员学习一个新软件的时候，不能满足于只学习基本的使用技巧。同样，只明白软件正常情况下的运行原理也是不够的。系统管理员必须要搞懂如果出了问题，可以在哪里得到帮助，错误代码文档、FAQ、以及支持渠道都有哪些。学习最直接的方式，就是试试看把它搞挂以后怎么恢复。
第三个建议：制定问题处理流程。系统管理员每次遇到的问题不一定都很难，通常最大的挑战是如何快速的定位问题，并找到故障恢复的方法。“时间”往往是你最大的约束。一个生产问题涉及多个系统部件是很常见的情况，每一个系统部件都有自己的日志，错误代码，trace 等等。光收集信息就会有很多种不同的路径。如果有多人一起参与问题处理，互相之间如何高效的合作也是问题。理顺这些部分最简单的方法就是事先制定好问题处理流程，并且在每次问题响应过后进行及时的复盘和调整。
第四个建议：学会分工。处理生产问题的时候，技术层面的诊断只是一个环节。还需要有人专门负责和业务流程的上下游团队进行沟通；还需要有人不停向各个受影响的领导们同步最新的进展。一个人是没有办法并行处理这些任务的，所以分工是必须的。大家可以轮流来担任不同的角色。不要怀疑，协调岗的压力和问题分析岗一样大。
系统管理员之路充满挑战，这里只是开了个头。如果大家有兴趣，可以留言和我进行交流。
