优先考虑devops待办事项的7个问题

许多组织正在采取步骤来采用devop最佳实践 ，在版本控制，持续集成，自动化测试，持续交付，部署容器，基础架构即代码，集中式监视以及其他方法方面进行投资，以实现对应用程序和基础架构的管理方面的自动化和系统化。

实践，工具和成熟度级别的列表正在增长，对于开发团队和技术组织而言，轻松确定要优先考虑的领域，最可行的方法以及足够好的成熟度级别已不再是一件小事。

[ 开发最佳实践：您应采用的5种方法 。 • 如何使测试自动化与敏捷性和发展性保持一致 。 •InfoWorld解释了在设备开发时代的监视 。 • 什么是devops？ 探索如何改变软件开发 。 ]

例如，进行大量应用程序开发的组织可能希望完全实现CI / CD（ 持续集成和交付），以便他们可以更频繁，更可靠地发布代码。 但是，每年仅执行有限数量部署的组织可以选择使其部署管道的某些部分自动化，然后希望集中监控以提高其对生产事件的响应时间 。

DevOps的团队有更实际的选择，作为工具AIops ， 管理微服务 ， 自动化安全 ， 管理multicloud环境 ，和其他DEVOPS趋势成为主流。 考虑到这一点，开发团队需要制定一项战略，以优先考虑其工作的努力程度和复杂程度，以说明在任何一个领域进行投资的原因，地点和数量。

这里有七个问题可以帮助您确定策略。

1.谁是您的客户，他们的优先级是什么？

这个问题使与我合作的许多开发团队感到惊讶，因为他们从未将其开发目标和优先事项视为面对客户。 但是，将用户角色和单独的购买者角色分配给每个技术计划（尤其是开发人员）可以使您清楚地关注重点，需要解决的问题，要考虑的技术解决方案以及如何最佳地实现自动化。

旨在提高开发团队效率（例如CI / CD）的Devops做法可能会被软件开发人员优先考虑，而AIops和集中式监视则可能会被运营工程师优先考虑。 因此，devops团队还应该考虑买方角色，或更具体地说，是组织中赞助和投资devops实践的领导者。 如果他们的战略需求不明确，则直接问他们。

2.您的技术运营模式是什么？

第二个问题困扰着许多开发团队。 组织是否采用devop做法和文化变革来推动更多类似创业的行为和能力？ 还是优先考虑启用类似企业的功能和性能指标？

这里有些例子。 您的CI / CD是更频繁发布还是更可靠发布？ 您是要为开发人员提供云原生开发沙箱，还是更重要的是使用cookie切割器基础架构部署来实现上下一致的开发环境？ 您是在基础架构和运营周围部署基本的运行状况检查，还是需要更强大的监视测试来支持预期的性能和其他站点可靠性指标？

显而易见的答案是，许多开发团队都希望以上所有这些。 实际的答案是每种方法都需要不同的实施和投资。 了解您的组织正在努力争取的文化可以帮助设置优先级和实施选项。

3.您的操作缺陷是什么？

要解决的另一个主题是技术部门遇到的运营问题。 企业领导者在抱怨什么？ 客户和用户在哪里受苦？ 从执行的角度来看，技术组织的哪些领域正在失败，并且开发实践和工具能否推动运营变化和影响？

这种思路可以帮助创建重点领域。 例如，遭受中断的组织可能希望部署集中式监视和AIop； 其他遭受缺陷困扰的部署可能会从自动化测试开始。

4.您在哪里成长和扩展？

如果不是操作缺陷会推动团队发展，请考虑哪些活动正在增长，并可以从更多的自动化中受益。 增加开发团队的组织可能希望以代码的形式投资基础架构，以便更轻松地启动新的开发和测试环境。 其他要求可移植性以便将应用程序部署到多个云或地理位置的组织可能希望在容器上进行更多投资。 如果应用程序变得越来越重要，并且用户期望更高的服务水平，则AIops可能是优先考虑的适当领域。

对于较大的组织，由于不同的应用程序会导致不同的需求，因此这种类型的分析可能会给出全面的答案。 将答案与对用户需求和运营缺陷的分析相结合，应该可以更清晰地了解优先事项。

5.在哪里有改进合作的空间？

越来越成熟的IT组织希望通过发展来推动文化变革。 在这些组织中，软件开发团队与经常进行代码部署的压力不一样，这与运营团队为确保业务运营的可靠性和性能所必须遵循的章程脱节。 有助于平衡这些驱动因素的Devops做法可以帮助团队找到共同点和新的合作方式。

寻找功能失调的地区或技术学科之间的压力很大的地方。 这通常会在变更咨询委员会中发生，在该委员会中，应审查应用程序部署的运行准备情况。 这些会议通常会给那些不了解所有需求和风险的开发人员带来压力，而对于那些在应用程序未解决所有合规性和风险检查问题时必须暂停或延迟部署的工程经理而言，则更为困难。 部署方面的自动化可以帮助标准化方法，并将预期的行为更改为用代码自动化的行为。

6.技术债务在哪里影响日常运营？

技术债务是一个广义术语，涵盖了从需要一直重构的代码到需要更换的报废旧系统的所有内容。 许多技术组织还使用该术语来强调其技术领域中正在延缓开发工作或使其难以支持业务运营的领域。

但是技术债不仅体现在代码和系统中。 这也是技术团队运作方式的一个因素。 例如，如果支持团队在响应事件或请求时需要遵循手动步骤，则可能是技术债务的副产品。 容易出错的复杂操作程序通常指向应已自动化的领域。 其他支持范围较薄或仅需要一名主题专家亲自完成步骤的领域可能会带来巨大的业务风险或技术债务。

问题是这些操作是否比记录的更好自动化，以及新的devops工具可以在何处简化操作。

7.您要解决哪些关键绩效指标？

技术组织应使用度量标准来评估其性能，并说明技术和实践改进在哪些方面产生影响。 部署基本的devop做法后，请选择和使用devops关键绩效指标 （KPI）。 该工具确定需要在哪里关注新重点以及要达到的成熟水平。

许多开发组织关注的一个KPI是应用程序部署的频率。 他们可以选择以更高的复杂度自动化更多的CI / CD管道，以实现更频繁的部署。 但是，如果他们还发现在生产中发现的缺陷数量不断增加（缺陷逃逸率），那么他们应该在测试自动化方面进行更多投资。

同样，经历长时间停运的组织可以选择衡量其平均恢复时间。 对集中监控，AIops，自动化测试和基础架构（作为代码）的投资都可以帮助改善此性能指标。

如果您使用KPI来确定优先级，那么需要探讨的关键问题是所选的KPI是否符合业务需求并解决了重要问题。 KPI应该是确定开发人员优先级的最终工具，但它们应体现用户需求，战略重点，缺陷，增长考虑因素以及其他驱动开发人员优先级的因素。

From: https://www.infoworld.com/article/3405526/7-questions-to-prioritize-your-devops-backlog.html