我眼中的DevOps(2)

所以,流程绝对不会从头到尾一帆风顺,所以我们要把每一步流程都认真对待,找出所有潜在的问题和障碍.跟软件产品一样,在流程的管理中也要有异常处理.我们不必做到精确预见每一个问题,但一定要保证：即使流程出错,它还能往下走.

把不同领域的所有流程串到一起.这些领域包括：部署、监控、能力计划(capacity planning) 等等.从逻辑上讲,“部署”是软件开发周期的最后一环,所以它应该属于“开发流程”,而非“运维流程”.另一个例子是度量和监控.在开发领域,如果不理解 底线标准和估算,就什么评估都做不了.把开发部门和运维部门的流程衔接在一起,也会让两个部门更好的配合、相互理解、承担共同的责任.最后还有个优点：文 档只需要一份而不是两份(开发一份、运维一份),从而节省了资金.

自动化,自动化,还是自动化.构建或使用简单、可扩展的工具(确保提供API,机器可读的输入、输出 — 参考 James White的文章：Infrastructure Manifesto).使用Puppet一 类的工具做配置管理.要扩展这些自动化工具,使其能够支持多个领域(开发领域和运维领域),并且在产品的不同环境(开发环境、测试环境、发布环境和生产环 境)中使用相同的工具(也叫end-to-end).这样不但会在产品支持和管理方面带来经济效益,而且也可以在编写新代码的同时,进行产品的发布和管 理.

最后,在构建流程和自动化时,要把KISS原则牢记于心.越复杂就越易错.只有简单的流程和工具才易于实现、易于管理和易于维护.

持续改进

不要停止创新和学习.当今技术发展的很快,客户的需求也往往如此.把“持续改进和持续集成” 加入到你的工具和流程中去,这也是运维人员向(优秀的)开发人员学习的好途径,可以学到诸如测试驱动开发等最佳实践.例如：可以向你的部署流程中加入单元测试.做监控时也应该增加些行为测试,提高交付质量.尝试用开发领域中的工具(例如Hudson)在运维领域中做些工作(例如浏览数据(explore)、测量性能(measure)等等).

要不断的总结教训.要积极主动的、在不同领域寻找错误的根源. 一旦收到错误报告,就果断把开发小组和运维小组找来,一起解决这个问题.有时候开发人员很简单的几次代码重构,就可以很好的避免底层运行环境的改变,减少 运维人员的负担.总之,遇到问题时,开发部门和运维部门要密切配合、共同解决,而不是互相推诿、踢皮球.

对我来说…

最后,对我来说,DevOps 的主要内容是：跟谁共同工作、如何共同工作.它最吸引我的地方就是致力于把不同部门不同分工的人召集到一起,共同努力解决问题.这样的工作环境,是我所憧憬的乐园.

作者 James Turnbull,译者 申思维

（编辑：ASP站长网）