一个开发对运维的一点反思

在工作了这些年里面回头总结一下工作中运维工作和自己的关系倒是可以看出来一个公司的发展路径。

刚毕业时候

进入的公司比较小，所做的工作并非是公司的主要盈利部分。我的工作是相当于内部工具。在当时是没有上线之后的运维的概念。一是对于业务的支撑工作不大。二是当时的软件部分很简单在，一次测试之后不会有什么变动。

工作两三年

这个时候的工作主要是在外包公司，当时的项目是简单的纯外包项目工作，这个阶段工作主要是因为为了赶进度所以主要工作是为了完成客户功能，而在项目完成之后我们外包公司就不在做项目的后期维护工作，所以对于项目维护是没有多少考虑，比如不是很考虑项目的后期扩展维护。就是只要公司赚了钱。

工作四五年

这个阶段的工作是加入了比较长时间在线运行的项目，这时间则是需要考虑项目的线上运行状态。这个阶段需要对线上运维有一些概念，但是在这个公司的时候则是因为产品已经有很长时间的运营，有比较好的盈利，所以有专门的的运运维团队来做这个事情。这也就导致我对运维工作的真实感受不强。

工作七年

这个时候在一个小的公司中作为项目负责人，这个时候则是经历的一个产品从无到有，从无到上线正式运营的过程。

自己理了一遍发现工作经历倒是每个阶段都有一定的代表性，从个人和公司的层面来说都是这样。
整个软件业的项目大多有这样的一个历程。

第一个阶段，很小的项目。

这样的项目一般功能很简单，完成之后几乎不再需要对客户提供进一步的维护服务，或者维护工作可以忽略不计。

第二个阶段，项目外包。

在自己没有稳定的项目和产品的情况，公司需要生存就会有这样的项目来维持。但是因为项目包的价格决定很大部分项目在完成之后就是一锤子买卖，为了赶进度完成项目功能，对项目的扩展性、可维护性就不会花太大的精力。导致之后的项目维护困难，扩展困难。又因为做这样的项目的发包方自己对软件项目了解不足，这些不足可能包含项目的难度，预算等条件。两方的这种心态最终很容易导致项目的失败。曾经我还见过因为项目的失败导致双方走上公堂的。

第三个阶段，有自己开发或者开发完成后承担长期维护的项目。

在这个阶段，可以算作一个产品的前期阶段，这个阶段大多数公司的盈利情况还不是很好，盈利情况一般比较少，所以投入相对有限，经常会由开发人同时做项目的维护人员。项目的例行维护势必会花费开发人员的一部分精力。这对于同时要进行开发的新功能进度会有一定影响。

第四个阶段，已经积累了比较多的客户，盈利情况比较稳定。

因为项目有了比较充足的盈利，客户已经比较多的情况下，为了给客户提供稳定的服务，项目的各个职能就会开始分散开来由专人来做，由原来的开发一把抓，变成有专门的测试人员，运维人员。这点倒是和社会发展的趋势一样，工作职位和专业越来越多。

在项目达到一定程度，拥有稳定客户盈利的时候，可以称作产品，这个时候就需要考虑产品的人员配置，新特性是否可以及时的发布，运行环境的安全性，线上环境是否能够保持稳定，维护成本，等众多影响因素。

项目越来越复杂，人员越来越多，就需要有合适的流程来组织各个职能的人员，让各个职能人员的工作可以使产品得到最好的成长。而在这个流程中需要大家对其他的职能有了解，如果有相关经验则是最好的。而一个开发有一个运维的心则是向高级开发，架构师发展必须要具备的心态。