自从 1 月 5 日开始实习至今，在 Operation Team 已经工作了三个月。我觉得有必要对工作进行一下总结。既是我对三个月来所学新知识的归纳，也是对运维工作的一些思考。
这次实习并非是我第一次接触运维工作。2014 年夏天，我有一份两个月的暑期实习。当时实习工作的职位是 *Backend Software Engineer*，但事实上所完成的绝大部分工作的内容是关于运维，主要有 AWS Auto Scaling 的搭建（关于这部分内容可以参见之前的一篇 博文）和基于 AWS Cloudwatch 实现一些监测工具。所以也算对运维工作有一些经验。之后在找实习的时候，我也是有意识地找运维相关的职位。
这里也顺便说一下暑期实习的公司。那是一个只有 5、6 个程序员的初创公司。公司所有的服务都搭建在 Amazon Web Service。运维可以说略显「简陋」：服务器的操作全部由 Python 脚本实现；代码的部署也是用 Python 脚本从 svn 下载再进行安装；系统监控全部部署在 Cloudwatch。对于只有十多台服务器的公司来说，这样的运维方法似乎也足够了。
所以在这次实习之前，我对运维工作的印象还是停留在启动、监控、维护服务器，写一些脚本来实现自动化，最多在服务器出问题的时候做一下 Hotfix。
但是当服务器数量到达几百台的时候，显然之前实习中所用的方法是不够的。这次实习所在公司的规模要比之前大得多，在 AWS 上大约有 350 台实例。因此接触到了更加专业的运维工具、工作方法和流程，对运维工作也有了更加深刻的认识。
先说工具的使用。和开发、测试不同的是，运维工作会接触到各种工具，最近几个月接触到的工具包括：
最让我印象深刻的应该是 Jenkins，第一次见识到自动化 CI 的感觉大概就和当年用了一学期 Turbo C 后第一次见到 Eclipse 一样。
每一个工具都自成体系，组合在一起又成为了相当复杂的运维系统。争取未来一段时间内，写一些文章来总结这些工具。
Welcome to Operation team! Every Ops guy has crashed a server.
– 工作近一个月，我第一次弄崩服务器程序之后，同事如是说
一个体会是运维工作对知识面要求挺高的。要能够编程、测试，因为很多时候要自己实现工具，这个时候要自己编码，自己测试。而且知识点很繁杂，操作系统、网络、软件工程这些学科的知识都会经常使用。
另一个体会是运维工作不只是管理服务器、部署程序，而是深入到公司开发流程的各个方面。开发人员写的代码需要有工具能够自动运行测试，自动合并到 Master 分支。测试人员做完测试要生成测试覆盖率的报告。还有常规的服务器管理，系统监测，所有这些林林总总的基础设施搭建都需要运维团队来做。就连办公室断了网也是由我们组来处理。
更为重要的体会还是在于运维工作的方法学方面。总的来说，感觉运维工作在很大程度上要靠经验的积累。下面一些内容未必正确，但都是工作三个月来自己的切身感受。
- 对系统的熟悉重于对算法的掌握
并非算法不重要，而是运维工作更多的时间里是在和 API、工具打交道，需要自己设计算法的场合相对比较少。现在的 API、工具越来越强大，很多复杂的算法都已经被封装起来了，不需要程序员自己来实现。但是，运维工作对系统熟悉的要求比较高。具体来说，你需要清楚地知道当前系统里每个工具做什么，怎么做。对软件工程各个环节中可能用到的工具要有了解，至少知道它能干什么，不能干什么。而且你还要知道不同工具如何配合使用，因为很多任务需要系统内几个工具一起合作。
- 对一个任务具体过程的熟悉重于对编程细节实现
一方面，运维工作自身的编程工作一般都比较简单。以部署来说，借助于像 Chef 这样的自动化部署工具，软件包的下载、配置文件的修改等琐碎细节都已经被隐藏，只需要编写脚本定义部署的步骤就可以了。所以在准备部署一个服务的时候，我们不需要知道怎样下载软件包，如何读、写文件，但是要非常清楚地知道搭建这个服务要经过哪几个步骤。有时候甚可能还需要清楚地知道每个步骤的顺序，比如服务的配置需要改变，是先停止程序，还是先修改配置文件。这就要求对每个任务的流程都很熟悉。
另一方面，运维不像开发那样需要知道公司业务的细节。运维工作是独立于公司业务的，不需要相应的 Domain Knowledge。我至今也不太了解公司核心业务是如何实现的。
- 成本估算的能力
运维工作是以成本为中心的。在公司里不能带来实际的收入，我们需要做的是花尽可能少的钱来提高公司的效率，保证服务的稳定。所以在接手一个任务之前，要估算不同解决方案的成本。有时候遇到一个问题，市场上有现成的收费工具可以用。如果不想花钱，自己来实现需要花费多少时间。
刚入职时的一个任务是：检查公司里几百台服务器是否有安全更新需要安装，要有通知功能，能够列出有哪些更新，并且支持一键安装。现成的解决方案有针对 Ubuntu 系统的 Canonical Landscape。功能齐全，界面美观，但是其价格到了瞠目结舌的地步，每 100 台机器一年要 $75K，难以想象一个 Linux 管理工具卖这么贵会不会有人用。这个成本显然是不能接受的。后来又找到一个独立开发者开发的补丁管理工具 Sysward，完全符合我们最初的需求，但是估算了一下，用这个每个月的费用仍然有 $700。最后考虑到这个需求并不是非常着急，而且在公司所使用的开源工具的基础上可以做出来，所以决定自己来做这个工具。
以上就是实习三个月以来，身为一个运维新人的体会和思考，想法或许还有些不成熟、不准确。实习还有四个月时间结束，希望届时能够有更多的体会可以总结。