目前，DevOps在国内正处于高速增长的阶段。尤其在各大厂中它受到了热烈欢迎，但是大家要注意结合实际，立足于业务。不能为了敏捷而敏捷，为了devops而devops!
目前，DevOps在国内正处于高速增长的阶段。尤其在各大厂中它受到了热烈欢迎，但是大家要注意结合实际，立足于业务。不能为了敏捷而敏捷，为了devops而devops!
[[361226]]
1. 部署频率
开发后保持竞争优势，高质量，准确地提供更新，新功能和技术增强都非常重要。增加交付强度的机会有利于提高灵活性并更满足不断变化的消费者需求。
定期测量部署频率将提供更大的可见性，可以了解哪些改进成功，哪些部分要更改。频率如果快速下降可能代表其他任务或手动操作在干扰工作流程。想要可持续的增长和发展，建议进行微小但持续变化的部署频率指标。确定部署频率，针对早期进行优化，使测试更易于管理。
2. 部署时间
此度量标准衡量执行部署需要多长时间看起来似乎无关紧要，但是衡量部署时间可以知道潜在问题。比如，如果你的部署需要一个小时，那一定有问题。所以最好集中在较小但更频繁的部署上，用捕获构建时间的方式。
3. 自动化测试通过率
非常建议你利用单元测试和集成测试以最大程度地提高速度。因为DevOps严重依赖于自动化，有用的DevOps指标用于衡量自动化测试的效果。知道多少代码调整会导致测试崩溃，有效利用这一点就可以帮到你。
4. 代码提交
计算团队在将软件实施到生产之前对软件的提交次数，不仅能衡量开发速度，还能衡量代码的准确性。团队应提出每个人该遵循的标准代码提交范围。大量提交或许意味着代码质量差、缺乏明确的开发目标之类的问题。团队可能会因为人数低于标准值而缺乏生产力。找出减少或增加提交次数的原因是非常有必要的，用来保持效率和项目进度，也可以保持团队成员之间的幸福感。
5. 计划外工作
顾名思义，在标准项目中，计划外工作率不应超过25%。太高的计划外工作率可能会在工作中发生一些意外错误，如果在工作流的早期没有发现就比较严重了。返工率也是试图解决票证中存在的问题的尝试。
平均故障时间(MTTF)是有缺陷的系统设法运行直到出现故障的平均时间。用来跟踪不可修复的系统组件的状态，并且评估它们在失效之前可以工作多长时间。它可以让DevOps团队在确定故障时维护关键任务系统的状况。
6. 应用性能
执行部署之前，你一定要检查性能故障，未知错误和其他问题。在整个部署过程中和部署之后监视整个程序输出中的更改。以及发布后的SQL查询，Web服务器调用和其他程序要求的使用。如果发生重大调整是正常的，可以使用监视工具，它可以更精确地显示更改。
7. 平均检测时间(MTTD)
当问题真正出现时，重点就是要立刻识别它们。不然出现严重的局部或大型机器故障时，还不了解它事态就会发展得很严重。记得设置强大的应用程序监视功能帮你轻松发现错误。
8. 平均恢复时间(MTTR)
平均恢复时间是衡量企业解决问题有效性的指标。分析业务和客户体验的效果的能力，提供了所需的视角。MTTR计算从故障到解决的总响应时间，并提供有关客户端是否失去控制，遇到延迟或放弃系统的信息。改善它可以大大地减少影响。
总而言之，在人力成本高、市场竞争激烈、以及用户需求变化十分频繁的情况下，DevOps是必须选用的一条路。
©本文为清一色官方代发，观点仅代表作者本人，与清一色无关。清一色对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文不作为投资理财建议，请读者仅作参考，并请自行承担全部责任。文中部分文字/图片/视频/音频等来源于网络，如侵犯到著作权人的权利，请与我们联系（微信/QQ:1074760229）。转载请注明出处：清一色财经
微信扫码打赏 
支付宝扫码打赏 
