七条2017的DevOps经验教训

对DevOps的使用来说，这是伟大的一年：那些在DevOps路上走的很好的公司分享以下建议。

任何预测2017年将是“DevOps之年”的人都得到了证明，在2017年比以往任何时候都有更多的企业抛弃旧方法、领导哲学和历史过程，以支持DevOps在当今不断发展的技术环境中实现速度和敏捷性。事实上，今年早些时候对700名IT专业人士进行的调查发现，50%的受访公司正在整合DevOps，或者今年已经这么做了，这已经远远超过临界质量。

我们学到了什么？如果你很早就开始了旅程，可能会有兴趣去了解那些使用DevOps公司所获得的最大的经验教训。我们已经把其中的7个圈起来了。如果你对DevOps更有经验，可以在留言中分享今年学到的最大的经验。

寻找广泛的技能

CollabNet的首席执行官Flint Brenton说：“DevOps把各个不同的团队聚集在一起，这意味着我们要招聘适应性强、乐于改变的人。”雇佣那些融入公司DevOps文化的人，可能意味着你要看看那些拥有更广泛或全面技能的人，以及那些喜欢跳出框框思考的人。所有年龄和背景的员工都有机会在这个DevOps框架中进行自我改造，这只会让希望雇佣有前瞻性的团队成员的科技公司受益。

纠正软件架构、交付和DevOps度量的正确问题

Electric Cloud首席技术官Anders Wallgren表示： “显而易见，除了DevOps的三大文化，流程和工具外，我们还需要花费时间和资源解决一些非常具体的问题，从而改进我们的DevOps工作：

1. 架构：软件架构很重要，松散耦合的架构与成功的DevOps成果高度相关，单一整体软件会造成软件pipeline架构的高度摩擦。

2. 测量：DevOps是一个持续改进的游戏，我们不能可靠地、反复地改进我们不能(或不做，也不可能不做)的措施。

3. 软件交付pipeline：软件交付pipeline中的手动步骤与延迟，错误和返工相关，这些都与良好的DevOps结果没有关系。“

开发参与运维

Datawire公司首席执行官Richard Li 说： “我们在2017年学到的最大经验教训之一是，当企业采用云原生应用的时候，DevOps绝对是必不可少的。正在构建云原生应用的开发人员在他们的服务上有运维责任时，他们的生产力会大大提高。例如，服务的开发人员可以更好地为服务指定资源需求(内存、CPU等)，而不是将责任委托给专门的运维工程师。组织面临的关键技术挑战之一是采用诸如Kubernetes这样的云原生技术，如何使开发人员拥有正确的运维控制级别。

不只是IT，不只是工具

CloudBees的首席执行官Sacha Labourey说：“我们学到的一个教训是，DevOps不能仅仅关注IT团队，这些原则也适用于非IT团队。这些原则很容易应用，因为DevOps更多的是关于文化，而不是技术技能。DevOps并不是一个万能的方法，当组织意识到对他们最有效的方法时，他们应该将这些知识扩展到非IT团队。有透明清晰的目标、目标和关键的结果，让整个团队都能保持一致，这有助于确保成功。”

“另一个教训是：DevOps不仅仅是关于工具的，实际上，从技术上来说，没有所谓的‘DevOps工具’，所以选择你正在进行业务关键操作的工具链是一个非常重要的战略决策。明智地选择，灵活地建立，并且知道你要去哪里。由于每个公司都将采用不同的方法来适应他们的基础设施和文化需求，所以技术的选择也将取决于每个公司的目标和目标。对改变持开放态度是第一步，为了保持竞争优势，定期对员工的当前和未来需求进行审计和评估，以获得成功。了解哪里还有痛点，知道你需要采取什么措施来继续快速增长的道路。”

从一开始就建立安全

DigiCert公司首席技术官Dan Timpson表示： “DevOps的安全整合正在发生，聪明的公司正在认识到，如果他们从一开始就把安全带入到这个过程中，他们就可以节省资金并且按时完成任务，避免安全问题在最后一刻发现可能导致项目中止的错误。在集成时，DevOps可以利用自动化的基本和重要的安全程序，如数字证书，提供身份验证和加密。使用API，我们可以将加密和身份验证构建到开发工作周期中。这有助于成功的持续发展，并将安全作为一项业务的当务之急。“

不要吝啬提前准备流程或工具

红帽技术推广工程师戈登·哈夫（Gordon Haff）： “每个人都得到了DevOps加速软件交付和更新速度的信息。但是DevOps团队的效率不高，他们发现他们为了获得这个速度而牺牲可靠性和恢复时间。DevOps领导者正在认识到，如果他们要兼具敏捷性，质量和安全性，他们需要投资建立正确的流程和预先实施正确的工具。“

围绕预期的变化建立团队知识

GeniusLink公司首席执行官Jesse Lakes 表示： “过去的一年对于Geniuslink的DevOps来说是忙碌的一年，我们在全年完成了许多具有挑战性的项目，这个最广泛和最具挑战性的项目仍在运行中，过渡到容器部署以支持独立的开发环境。在这一点上，我认为可以公平地说，我低估了所需的资源和时间表，以及团队对项目的中断。

不幸的是，由于突然需要了解Docker / Nomad / Consul，日常过程的变化（比如应用程序的构建/部署）以及实际的代码/配置变更，开发人员看到了显着的生产力影响。这些影响超出了原先预计的OPS方面的影响。任何参与类似工作的人都应仔细考虑在新技术方面建立团队知识，并慢慢进行流程变更，以尽量减少实际迁移的影响。

我能再做一次吗？当然，我是否会有不同的做法？你说的没错我还在学习，这是一件好事！在进入2018年之前，我肯定会实际评估DevOps的变化对我的开发/测试团队的影响，你也应该这样做。“