编程遇到难题怎么办_现场可靠性工程遇到发展难题的地方

编程遇到难题怎么办

早在云应用程序，开发人员实践，测试自动化和站点可靠性工程师出现之前，我们就有开发人员，测试人员和系统管理员来开发和支持Web和移动应用程序。 开发人员遵循敏捷方法 ，而系统管理人员通常采用ITIL的事件管理和其他实践 。

那时，我们使用的自动化测试，部署和基础架构的工具较少，因此从代码完成到生产就绪的工作量很大。 监视生产基础结构和应用程序以及发现生产问题的根本原因需要技巧和技能，因为操作数据，监视工具和支持工作流程不容易集成。

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

在许多方面，开发，测试和支持应用程序在今天已经有些容易了，但是术语，角色定义和实际责任却很难理解和应用。 站点可靠性工程是Devop的一部分还是一项补充服务？ 谁负责将CI / CD（连续集成/连续交付）管道和基础结构实现为代码？ 发生生产事故时，解决问题，发现根本原因并实施最佳补救措施的最有效流程是什么？

Google的文化和习惯可能不适用于您的组织

由于公司规模，规模和复杂性的差异，无法普遍应用答案。 对于只有几十名工程师的初创公司而言，有效的方法不适用于受管制行业中地理位置分散的企业。 同样，对于大型技术公司（例如Google，Netflix或Microsoft）而言，适用于大型技术公司的文化，实践和技术通常无法在具有更多传统系统和技术债务的其他行业或企业中实现。

为了达成共识，我建议围绕五个维度定义术语：

• 组织拥护的使命，文化，协作和心态
• 业务目标，客户定义，价值主张和成功KPI（关键绩效指标）
• 开发，测试，部署和监视应用程序的技术工作
• 团队用于计划，交付和支持应用程序的工作流程和实践
• 成功完成这项工作所需的工具和自动化

这看起来很简单，但是在实践中，组织的运作方式更混乱，实践边界也不太直接。 例如，我将敏捷方法定义为工作流实践，但是组织如何定义其敏捷实践取决于业务目标，技术架构，软件开发生命周期和适当的devops自动化。

对于开发人员的实践和文化与站点可靠性工程师的工作和职责的交集，也是如此。

关于devops和SRE（站点可靠性工程），有很多很多意见。 这是一个示例：

• Google定义了几个开发目标，包括减少组织孤岛，正常接受故障，实施渐进式变更，使用工具和自动化以及评估所有内容。 然后，Google提出了几种SRE运营模式 ，从具有全面章程的“一切SRE”到作为开发团队顾问且不太可能修改代码的模型。
• 计算机器协会为 SRE角色定义了一个以操作为中心的章程 ，并将监视，指标，紧急响应，容量规划，服务管理，变更管理和性能确定为SRE的核心功能。
• 另一篇文章试图阐明devop和SRE之间的区别 ，这表明“ Devops通常关注于什么，而SRE关注于如何 ”，但我也建议“ SRE非常适合于需要的企业和组织管理大型应用程序。”

我会质疑SRE主要针对大型组织的建议。 我认为，各种构建并支持定制应用程序，数据集成，数据科学实验和机器学习模型的组织都需要SRE来补充开发职责。 您可以在SRE的七种职责中更清楚地看到这一点， 这些职责包括按服务级别目标进行管理，最大程度地减少工作量并与开发人员共享所有权。 谁不需要拥有和解决这些责任？

将重点从系统管理转移到站点可靠性

在我的《 驾驶数字》一书中，我将SRE角色描述为“敏捷运营”。 我提出一个过于简单但通常不切实际的目标：“理想情况下，开发人员应该将70％至80％的时间用于与用户一起使用新功能，而理想情况下则仅将20％至30％用于支持 。” 从自动配置CI / CD管道到将基础设施实施为代码，以及自动进行应用程序监视，支持都是无功能的。

这些功能是必不可少的，但它们仅仅是使开发高效，一致和可靠的基础。 自动化需要编码，但是我宁愿让熟​​练使用Devops平台的工程师（例如Jenkins，CircleCI，Azure DevOps，Puppet，Chef，Ansible等）来实现它。

但是，在开发，测试和生产中确保可靠，高性能，可扩展和安全的应用程序也是一项重要职责。 越来越多的这项工作向左移，以便在开发和测试阶段识别并解决这些问题。 确保可靠性是团队的全部责任，但我希望团队中的其他人学习规程和工具，并负责实施。

十年前，业界称责任系统管理或系统工程。 如今，云基础架构，工具配置和自动化已实现了更高效的基础架构模式并减少了系统工作。 同样，由于自动化和诸如变更管理之类的控制已减少了一些工作，因此管理量大大减少。

开发人员和SRE必须就应用程序可靠性进行协作

如今，正式称为“系统管理”或“系统工程”的责任被更好地称为“站点可靠性工程”。 承担此角色的人员需要了解从基础架构到最终用户体验的性能。 它们是事件发生时的第一道防线，需要领导和技术责任来确定根本原因并纠正问题。

这些是SRE的被动职责，但更关键的技能和任务是主动职责。 这些职责和工具的外观取决于应用程序的性质。 它们可能包括自动化渗透测试，执行代码审查，运行性能测试以及重构代码，这些代码具有影响性能，可靠性或可伸缩性的非功能性技术债务。

开发人员的协作始于了解SRE角色以及开发职责在何处终止以及SRE开始。 即使有了这种了解，与开发人员相比，大多数组织的SRE要少得多，因此无论SRE位于何处，向谁报告，是否属于敏捷团队还是作为外部服务提供商，都需要进行协作。 尽管SRE应该使用与开发人员相同的工具和开发实践，但是分配给他们的工作是什么，以及开发人员实现的模式或最佳做法是由许多因素决定的。

为什么这很关键？ 因为没有人希望持续发生影响最终用户和客户的消防事件。

翻译自: https://www.infoworld.com/article/3489799/where-site-reliability-engineering-meets-devops.html

编程遇到难题怎么办