运维DevOps体系解析与落地实践

高风险的变更仍然需要人工审核介入，但审核的内容由原来的执行步骤转变为需求是否合理以及操作时间是否合理。ITIL的变更流程依然存在，只不过蜕化为第二层，对用户不可见，蜕化后的系统结构如下图：

如何持续改进?

评价DevOps的指标有两个，一个是整个变更的平均完成时间，这个时间可以分为高风险，中风险和低风险三个纬度，我们目标是降低低风险和中风险的变更时间，高风险一般不做时间要求。另外一个是研发的自助变更率，当然，有些变更必须运维才能完成，这类变更在统计时要排除在外。

总结

DevOps落地过程中最麻烦的是观念转变，既原来运维的工作开发凭什么承担，这就需要前期的宣导培训，最好是让部分开发参与到前期DevOps系统需求中来，让大家看到实实在在的好处，不能为了DevOps而DevOps。

DevOps和ITIL二者理念不同，但关注点相似，并不存在必须舍弃一种的说法，可以在质量和效率之间选取平衡。如果说ITIL需要自上而下贯彻实施，那么DevOps则需要变更的执行者、需求者参与，二者最后会贯穿整个链路。

最后，还是那句话，没有好不好，只有合不合适，只有最合适的，才是最好的。

【编辑推荐】

1. DevOps工程师实际上是做什么的？
2. 2018年值得推荐的10个开源DevOps工具！
3. DevOps性能测试的优秀实践与工具
4. 把运维和开发放一起就是DevOps？还差得远！
5. DevOps对你意味着什么？

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!