[译]什么是DevOps？
原文地址：https://docs.microsoft.com/en-us/azure/devops/learn/what-is-devops 作者：Sam Guckenheimer
DevOps是人员，流程和产品的结合，目的是向最终用户提供价值的持续交付。 “开发”和“运维”的一体化是指将孤立的开发和运维替换为：基于共享和高效的实践和工具协同的跨学科团队。DevOps基础实践包括敏捷规划，持续集成，持续交付和应用程序监控。
进入DevOps
不要害怕DevOps。 一些团队诞生于DevOps; 一些团队实现DevOps; 其他团队通过DevOps推动他们.什么是DevOps？ 为什么DevOps很重要？ 为什么现在？ 你如何成功实现DevOps？ 这些是我们想要了解的主题。
理解周期时间
让我们从关于软件开发的基本假设开始。 我们将用OODA循环来描述。OODA循环最初是为了防止战斗机飞行员被空中射击而设计的，是一种考虑保持领先于竞争对手的好方法。 首先要观察业务、市场、需求、当前用户行为和可用的遥测数据。 然后可通过面对枚举选项来确定可以交付的内容，也许还可通过实验方法来确定。 接下来决定要追求的内容，并通过向真实用户交付可工作软件来采取行动。 所有这些活动都发生在一些循环时间内。
数据驱动
但愿基于数据来驱动下一周期的动作。 许多经验报告表明，大约三分之一的部署将产生消极的业务结果，大约三分之一将产生积极的结果，三分之一将没有任何改变。 理想情况下，希望在那些不能推动业务发展的情况下能够快速失败，并在那些推进业务的情况下加倍努力。 有时这被称为转型或坚持。
验证学习
快速失败或加倍努力的速度取决于循环所需的时间长度或者精益方法中的周期时间。 循环时间决定收集反馈的速度，以确定下一循环中发生什么。 在每个周期收集的反馈应该是真实的，可操作的数据。 这称为验证学习。
缩短周期时间
采用DevOps实践时，可通过更小批量工作，应用更多自动化，强化发布流水线，改进遥测以及更频繁地部署来缩短周期时间。
优化验证学习
部署频率越高，实验次数越多，就越有机会转型或坚持，并在每个周期中获得验证学习。 验证学习中的这种加速是改进的价值。 将其可视为实现的改进以及所避免的失败的总和。
如何实现DevOps
请记住，目标是缩短周期时间。 从发布流水线开始。 部署一行代码或配置的更改需要多长时间？ 最终，这就是你的速度制动。
持续集成
持续集成推动了代码的持续合并和测试，从而在早期发现缺陷。 其他好处包括减少浪费合并问题的时间和开发团队的快速反馈。
持续集成（CI）是每次团队成员提交版本控制更改时自动构建和测试代码的过程。 CI鼓励开发人员在每个小任务完成后通过将他们的更改合并到共享版本控制存储库来共享他们的代码和单元测试。提交代码会触发系统的自动构建，以从共享存储库中获取最新代码，并构建，测试和验证完整的master分支（也称为主干或主分支）。
CI之所以成为最佳实践，是因为软件开发人员经常独立地工作，然后他们需要将其更改与团队的其他代码库集成。等待几天或几周的代码集成会产生许多合并冲突、难以修复错误、有分歧的代码策略及重复工作。 CI要求将开发团队的代码持续合并到共享版本控制分支以避免这些问题。
CI保持master分支干净。团队可以利用现代版本控制系统（如Git）创建短期功能分支以隔离其工作。当功能完成时，开发人员提交“pull request”，并且在PR批准时，将变更合并到master分支中。然后开发人员可以删除之前的功能分支。开发团队重复该过程以进行额外的工作。团队可以建立分支策略以确保主分支符合期望的质量标准。
团队使用构建定义来确保对master分支的每次提交都会触发自动构建和测试过程。 以这种方式实现CI可确保在开发周期的早期捕获错误，从而降低修复成本。 为每个构建运行自动化测试，以确保每次构建都保持一致的质量。
阅读有关Azure流水线的持续集成功能的更多信息。
了解如何为任何平台设置持续集成。
持续交付
持续向生产和测试环境提供软件解决方案可帮助组织快速修复错误并响应不断变化的业务需求。
持续交付（CD）是从构建到生产环境的构建、测试、配置及部署的过程。多个测试或预发布环境创建一条发布流水线来自动创建基础设施和部署新的管道。持续环境支持逐步执行的集成，负载和用户验收测试活动。持续集成启动CD过程，并且在成功完成测试后，流水线将每个持续环境晋级到下一个环境。
持续交付可以对多个部署“环”进行排列以进行渐进式曝光（也称为“控制爆炸半径”）。渐进式曝光组内的用户可以尝试使用新版本并在“环”中的监控他们体验。第一次部署环通常是一个“金丝雀”，用于在更广泛的部署之前测试生产环境中的新版本。 CD自动化从一个环到下一个环的部署，并且可基于审批步骤进行可选，其中审批者以电子化方式签署变更。 CD可以创建审批的审批记录，以满足监管程序或其他控制目标。
如果没有持续交付，软件发布周期以前是应用开发和运维团队的瓶颈。手工过程导致延迟和错误的不可靠的发布。这些团队经常依赖于在发布周期中导致问题的交接。自动发布流水线允许“快速失败”的验证方法，其中最可能快速失败的测试最先运行，而需要较长时间运行的测试在其成功完成之后进行。
持续交付是一种精益实践。 CD的目标是通过实现从版本控制中的新代码可用或包管理中的新组件到部署的最短路径来保持生产更新。通过自动化，CD最大限度地缩短了部署时间，减少了修复生产事件（TTM和TTR）的时间。用精益的话说，这优化了处理时间并消除空闲时间。基础设施即代码和监控的两个互补实践极大地促进了持续交付。
持续交付价值已成为组织的强制性要求。为了给最终用户创造价值，必须持续不断地发布。
用于顺序环旁边的渐进式曝光，持续交付还支持两种其他模式。 “蓝/绿部署”依赖于在部署新（绿色）版本时保持现有（蓝色）版本。通常，这使用负载平衡来将增加的流量引导到绿色部署。如果监控发现事件，则可以将流量重新路由到仍在运行的蓝色部署。 “特性标记”（或“特性开关”）包括用于实验和“暗启动”的另一种技术。特性标记基于其身份和成员组身份为不同的最终用户打开或关闭特性。
现代发布流水线允许开发团队快速安全地部署新功能。通过推出新部署，可以快速修复生产中发现的问题。通过这种方式，CD可以创造持续的客户价值流。
详细了解Azure流水线的持续交付功能。
了解如何设置Azure的持续部署。
了解Bing如何使用Azure DevOps进行持续交付。
版本控制
版本控制，通常使用Git，使位于世界任何地方的团队能够在日常开发活动中有效地进行协同，并与用于监视部署等活动的软件开发工具集成。
敏捷规划和精益项目管理技术
敏捷规划和精益项目管理技术用于规划和隔离工作到Sprint，管理团队能力，并帮助团队快速适应不断变化的业务需求。 一个DevOps的DoD（完成定义）是用于收集遥测是否符合预期业务目标的可工作软件。
监控和日志
监控和日志正在运行的应用程序，包括应用程序建康度和客户使用率的生产环境，可帮助组织形成假设并快速验证或反驳策略。 捕获的丰富数据以各种日志记录格式存储。
监控提供生产反馈。 监控提供有关应用程序性能和使用模式的信息。
监控的一个目标是通过最小化检测时间和缓解时间来实现高可用性（TTD，TTM）。 换句话说，TTD是一旦出现性能和其他问题，相关问题的丰富诊断数据将通过自动监控反馈给开发团队。 TTM是DevOps团队根据信息采取行动，尽快缓解问题，使用户不再受到影响。团队随着时间的推移不断改进测量问题解决时间， 在缓解之后，团队致力于如何从根因上解决问题，以便问题不再发生， 该时间以TTR衡量。
监控的第二个目标是通过跟踪使用来启用“验证学习”。 验证学习的核心概念是每次部署都是跟踪实验结果的机会，这些实验结果支持或反对导致部署的假设。 通过跟踪版本之间的使用和差异，团队可以衡量变更的影响并推动业务决策。 如果反对假设，团队可以“快速失败”或“转向”。 如果支持假设，那么团队可以加倍或“坚持”。 这些数据通知决策导致新的假设和backlog的优先次序。
“遥测”是从监控中收集数据的机制。 遥测可以使用部署环境中安装的代理、依赖于注入源代码中的标记的SDK、服务器日志记录或者是这些方式的组合。 通常，遥测技术将区分针对实时警报和仪表板优化的数据管道以及故障排除或使用分析所需的更高容量数据。
“综合监控”使用一组一致的事务来评估性能和可用性。 综合事务是可预测的测试，其优点是允许以高度可预测的方式从发布到发布进行比较。 另一方面，真实用户监控（RUM）意味着测量用户浏览器，移动设备或桌面的体验，并考虑“最后一英里”条件，如蜂窝网络，互联网路由和缓存。 与综合监控不同，RUM通常不会随时间提供可重复的测量。
监控通常用于“在生产中测试”。 受到良好监控的部署会对有关其运行状况和性能的数据进行流式处理，以便团队可以立即发现生产事件。 联合持续部署发布流水线，监控将检测新的异常并允许迅速进行缓解。 这允许发现在预生产环境中无法预见应用程序行为中的“未知的未知”。
有效的监控对于DevOps团队快速交付、从生产中获得反馈以及提高客户满意度、获取及留存至关重要。
阅读有关Application Insights的监控功能的更多信息。
了解如何设置和使用Application Insights进行监控。
公有云和混合云
公有云和混合云使之难以置信的简单。 云已经消除了传统的瓶颈，并帮助将基础设施商品化。 无论使用基础架构即服务（IaaS）来提升和迁移现有应用程序，还是使用平台即服务（PaaS）来获得前所未有的生产力，云都可以提供无限制的数据中心。
基础设施即代码
基础设施即代码（IaC）是一种实现环境创建和拆除的自动化和验证的实践，以助于提供安全和稳定的应用程序托管平台。
基础设施即代码（IaC）是描述性模型中的基础设施（网络，虚拟机，负载平衡器和连接拓扑）的管理，使用与DevOps团队用于源代码的版本相同的版本。 与同源代码生成相同二进制文件的原则一样，IaC模型在每次使用时都会生成相同的环境。 IaC是DevOps的关键实践，与持续交付结合使用。
基础设施即代码用于解决发布流水线中的环境漂移问题。 如果没有IaC，团队必须维护各个部署环境的设置。 随着时间的推移，每个环境都变成了雪花环境，即一种无法自动复制的独特配置。 环境间的不一致会导致部署期间出现问题。 对于雪花环境，基础设施的管理和维护意味着难以跟踪并导致错误的手工过程。
幂等性是基础设施即代码的原则之一。 幂等性是部署命令始终将目标环境设置为相同配置的属性，无论环境的初始状态如何。 通过自动配置现有目标或通过丢弃现有目标并重新创建新环境来实现幂等性。
因此，通过IaC，团队对环境描述进行变更并对配置模型进行版本化，通常采用记录良好的代码格式（如JSON）。发布流水线执行模型以配置目标环境。如果团队需要进行变更，他们会编辑源代码，而非目标环境。
IaC使得DevOps团队可以在开发周期的早期阶段在类生产的环境中测试应用程序。这些团队希望可靠地按需配置多个测试环境。IaC也可以进行防止常见的部署问题验证和测试。同时，云基于IaC定义动态地提供和销毁环境。
实施IaC的团队可以快速，大规模地提供稳定的环境。 团队通过代码表示环境的期望状态，从而避免手动配置环境并强制实现一致性。 使用IaC进行基础架构部署是可重复的，可防止因配置漂移或缺少依赖性而导致的运行时问题。 DevOps团队可以与一组统一的实践和工具协同工作，快速地、可靠地、大规模地交付应用程序及其支持基础架构。
通过Azure Resource Manager了解有关基础架构作为代码的更多信息
微服务架构
利用微服务架构将业务用例隔离成通过接口契约进行通信的小型可重用服务。 该架构实现了可扩展性和效率。
容器技术
容器是虚拟化的下一个发展阶段。 容器比虚拟机更加轻量，可以更快地进行融合，并且可以通过文件轻松配置。
DevOps初始会带来的疼痛
如果感到疼，就更频繁地去做。 就像去健身房一样，采用新的方法一开始可能会受到伤害。 练习新方法的次数越多，就越容易。 就像在健身房训练一样，在锻炼小块肌肉之前锻炼大块肌肉，采用最具效力的练习并交叉训练以发挥协同作用。
参考文档
-
(Gartner) “Gartner Says By 2016, DevOps Will Evolve From a Niche to a Mainstream Strategy Employed by 25 Percent of Global 2000 Organizations”, http://www.gartner.com/newsroom/id/2999017
-
Gene Kim, Jez Humble, Patrick Debois, & John Willis, The DevOps Handbook, 2016, p. xxi
-
Apologies to William Shakespeare, Twelfth Night
-
Boyd, John, R., The Essence of Winning and Losing, 28 June 1995 a five slide set by Boyd. See also Adrian Cockcroft, http://www.slideshare.net/adriancockcroft/speeding-up-31799721
-
Kohavi et al. http://ai.stanford.edu/~ronnyk/ExPThinkWeek2009Public.pdf
-
Eric Ries, Lean Startup
- 版权声明： 本博客所有文章除特别声明外，均采用 CC BY-NC-SA 3.0 许可协议。转载请注明出处！
