大家好！
我们已经出版了《 DevOps哲学》
一书 ，并且我们还计划针对这一主题编写一本新书。
很多关于DevOps是什么以及不是DevOps的副本以及DevOps与持续集成之间的关系被打乱了。 因此，我们请您尽可能客观地发表讲话，您是否同意当今作者亚当·麦凯（Adam Mackay）（Adam Mackay）关于DevOps本质的观点？或者，您认为他提出的观点有些不完整或有偏见？
我们阅读并发表评论！
我一生都在技术领域工作，在我眼前，几种软件开发方法已经成熟并形成。 它们的大多数思想都以常识的精神归结为通常的生产率优化，它们是从经济的不同部门借来的。 几年前，每个人都希望从瀑布式开发模型过渡到敏捷，敏捷开发。 我最近去一家进步公司工作，他们正在尝试实施DevOps。 Verifa这家公司长期以来一直坚持敏捷，并试图将这种模型的优势不仅扩展到软件开发，而且还扩展到整个业务。
DevOps是软件行业中的一个新术语。 这个概念结合了许多有关集成业务和开发的合理想法，并且制定了一种叙述方式，使我们可以在单个上下文中讨论软件的开发，交付和操作。
DevOps是一种方法，开发工程师和管理工程师可以通过这种方法共同参与软件产品的整个生命周期，从设计和开发到全面的产品支持。 因此，DevOps旨在消除传统的不统一，其中一个团队编写代码，另一团队测试代码，第三团队部署，第四团队负责操作。
借助DevOps，系统管理员员工开始在委托给他们的系统的支持下使用开发人员库中已修复的许多技术。 在DevOps中，系统工程的构建完全类似于开发过程中的任务流。 所有资源都输入到源会计系统中，并进行适当的测试。
我们公司中有几个关键的DevOps主题：价值，原则，方法，实践和工具。
价值观任何工程师都因寻求解决方案而入狱，这种抱负有时会转化为对新技术的拒绝，是对新事物进行试验的不愿，这种表达方式以不同的方式体现出来：从“拒绝他人的发展综合症”到捍卫利基市场的适得其反的尝试。 要真正过渡到DevOps，必须首先认识到这些偏见，然后加以克服。 如果您不了解什么是价值主张，那么任何技术，Docker，Kubernetes或Amazon Web Services都无法解决您的问题。
“牵手朋友！”
Unsplash的Rawpixel快照原则我们公司的原则基于“三种方式”模型。 它由“ Visible Ops”和“ The Phoenix Project”的作者Gene Kim和“ Lean IT”的作者Mike Orzen开发。 我们建议营造一种环境，在这种环境中激发系统性思维，加强反馈周期并灌输不断进行实验和学习的文化。
不断思考整个系统。 问问自己：“您如何获得更多反馈循环？” 监视，指标和日志记录是其中三个周期，可帮助管理员参与设计。 在健康的DevOps环境中，可以刺激促进建立短而有效的反馈周期的过程，这些过程的示例包括事件管理，事后分析的客观性，透明度...
“ MacBook Pro之前的握手”，来自
Unsplash的rawpixel快照
方法灵活的管理灵活=简单。 将您的项目划分为小范围的工作，进行构建，限制进度限制，实施反馈循环并实现可视化。 这是我在任何项目中最喜欢的元素； 灵活的管理技术可提供更有效的输出，包括提高系统吞吐量和稳定性； 员工在工作中的压力减少，获得了更高的工作满意度。
首先是人，然后是流程，然后是工具DevOps先驱提出的第一种方法论是“首先是人，然后是过程，然后是工具”。 在我们公司中，建议您首先同意由谁负责特定工作任务。 然后，我们确定解决此问题所需的流程。 之后，选择实现该过程所需的工具。 从表面上看，所有这些似乎合乎逻辑，但是，工程师和经理经常屈从于吸引人的“急于获得它！” 从供应商那里，在这种情况下，他们正试图做相反的事情：购买工具，然后为它形成整个任务流程。
持续交付这个词在每个人的嘴上都是如此，以至于有时甚至被误称为DevOps。 原则上，这是动态编程和软件测试的实践，可快速发布非常小的，完整的，现成的片段。 通常，连续交付可以提高整体质量和速度。 持续交付是项目的关键组成部分，必须尽早建立，这是成功实施DevOps的驱动因素。
变更管理
以我的经验，系统的运行状况与变更管理的组织方式之间存在直接的关联。 这并不意味着您需要实施传统控制，这会减慢开发速度，并且比提供帮助更有害。 在这种情况下，您需要一个可扩展且可靠的平台来持续交付。 专注于消除脆弱的工件，构建过程的可重复性，管理依赖项以及创建有利于持续改进的环境。
代码中的基础结构（代码中的配置...代码中的所有内容）当前公司使我受益匪浅的启示之一是，任何系统都可以而且应该被解释为代码。 将系统规范输入版本控制系统中，并进行同行评审。 使用现代部署机制，尤其是Docker和Kubernetes，您可以根据规范自动构建，测试和创建实际系统，并以编程方式对其进行管理。 这种方法使您可以编译和运行系统，而不必进行费力的长期工作，随着时间的推移，这变得非常困难。
练习在我工作过的所有以前的IT组织中，项目的方法是：“让我们写点东西，然后我们将指导某人进行测试和部署。” 这种方法与计划不太吻合，因为时间变化，当开发团队转到下一个项目时，运营成本变得难以承受。
“在蓝天白云下的过山车”，
Unsplash拍摄的
Priscilla Du Preez的快照
在当前的组织中，我们努力使开发人员与他们创建的服务保持同步，并对它的运行负部分责任。 结果是更有效的反馈周期，不仅可以帮助团队更快地对错误做出响应，还可以对新功能做出更快的响应，并确保产品朝着正确的方向发展。
工具我们喜欢我们的工具！ 他们帮助工程师对系统和应用程序进行编程，组装，测试，打包，发布，配置和跟踪。 我们精通工具，并了解我们感兴趣的所有解决方案-开源和商业。 在DevOps范式开始发展之前，创新和工具一直处于停滞状态。 长期以来，我一直使用与职业生涯初期相同的工具（自2000年以来一直从事编程工作）。 DevOps中使用的许多工具都具有惊人的通用性，可帮助您以全新的方式组织服务生命周期。
Unsplash的
Barn Images系列中的“车间中的各种木工工具”
您需要为DevOps选择可靠的工具。 没有适用于所有情况的单一工具，您需要一整条生产线，可以结合现有需求来组合其清单。 而且由于我们希望所有这些都可以协同工作……任何工具都只有在帮助整个系统时才有用。
您需要选择与库存中其余部分配合使用的工具。 工具应有助于自动化任何工作。 它们应该易于从API或命令行调用。 原则上，即使在集成良好的工具中，高度依赖UI的工具也不太适合。
接下来是什么...下载Docker映像并开始实验。 分叉别人的代码并开始构建它。 使用Kubernetes部署服务器或服务器集群 所以您要做DevOps。 在您自己的计算机上启动，然后转到云。
Unsplash的塞缪尔·泽勒 （ Samuel Zeller）拍摄的“一个站在楼梯上，伸手要冲云的男孩”当您首次听到“代码中的基础结构”或“连续交付”的范例时，您会立即说“不，它与我们的工作原理有所不同”。 但是，为了成功使用DevOps，您需要逐步掌握这些技术，它们并不那么复杂。 多年以来，该行业一直使用与DevOps相反的方法，但是DevOps确实有效。