DevOps 是一种持续性的改变和提高：那么也准备改变你所珍视的领导力准则吧。

如果 [DevOps] 最终更多的是一种文化而非某种技术或者平台，那么请记住：它没有终点线。而是一种持续性的改变和提高——而且最高管理层并不及格。

然而，如果期望 DevOps 能够帮助获得更多的成果，领导者需要修订他们的一些传统的方法。让我们考虑 7 个在 DevOps 时代更有效的 IT 领导的想法。

1、 向失败说“是的”

“失败”这个词在 IT 领域中一直包含着非常具体的意义，而且通常是糟糕的意思：服务器失败、备份失败、硬盘驱动器失败——你的印象就是如此。

然而一个健康的 DevOps 文化取决于如何重新定义失败——IT 领导者应该在他们的字典里重新定义这个单词，使这个词的含义和“机会”对等起来。

“在 DevOps 之前，我们曾有一种惩罚失败者的文化，”Datical 的首席技术官兼联合创始人罗伯特·里夫斯说，“我们学到的仅仅是去避免错误。在 IT 领域避免错误的首要措施就是不要去改变任何东西：不要加速版本迭代的日程，不要迁移到云中，不要去做任何不同的事”

那是一个旧时代的剧本，里夫斯坦诚的说，它已经不起作用了，事实上，那种停滞实际上是失败。

“那些缓慢的发布周期并逃避云的公司被恐惧所麻痹——他们将会走向失败，”里夫斯说道。“IT 领导者必须拥抱失败，并把它当做成一个机遇。人们不仅仅从他们的过错中学习，也会从别人的错误中学习。开放和安全心理的文化促进学习和提高。”

相关文章：[为什么敏捷领导者谈论“失败”必须超越它本义]

2、 在管理层渗透开发运营的理念

尽管 DevOps 文化可以在各个方向有机的发展，那些正在从单体、孤立的 IT 实践中转变出来的公司，以及可能遭遇逆风的公司——需要高管层的全面支持。如果缺少了它，你就会传达模糊的信息，而且可能会鼓励那些宁愿被推着走的人，但这是我们一贯的做事方式。改变文化是困难的；人们需要看到高管层完全投入进去并且知道改变已经实际发生了。

“高层管理必须全力支持 DevOps，才能成功的实现收益”，来自 Rainforest QA 的首席信息官德里克·蔡说道。

成为一个 DevOps 商店。德里克指出，涉及到公司的一切，从技术团队到工具到进程到规则和责任。

“没有高层管理的统一赞助支持，DevOps 的实施将很难成功，”德里克说道，“因此，在转变到 DevOps 之前在高层中保持一致是很重要的。”

3、 不要只是声明 “DevOps”——要明确它

即使 IT 公司也已经开始张开双臂拥抱 DevOps，也可能不是每个人都在同一个步调上。

参考我们的相关文章，[3 阐明了DevOps和首席技术官们必须在同一进程上]

造成这种脱节的一个根本原因是：人们对这个术语的有着不同的定义理解。

“DevOps 对不同的人可能意味着不同的含义，”德里克解释道，“对高管层和副总裁层来说，要执行明确的 DevOps 的目标，清楚地声明期望的成果，充分理解带来的成果将如何使公司的商业受益，并且能够衡量和报告成功的过程。”

事实上，在基线定义和远景之外，DevOps 要求正在进行频繁的交流，不是仅仅在小团队里，而是要贯穿到整个组织。IT 领导者必须将它设置为优先。

“不可避免的，将会有些阻碍，在商业中将会存在失败和破坏，”德里克说道，“领导者们需要清楚的将这个过程向公司的其他人阐述清楚，告诉他们他们作为这个过程的一份子能够期待的结果。”

4、 DevOps 对于商业和技术同样重要

IT 领导者们成功的将 DevOps 商店的这种文化和实践当做一项商业策略，以及构建和运营软件的方法。DevOps 是将 IT 从支持部门转向战略部门的推动力。

IT 领导者们必须转变他们的思想和方法，从成本和服务中心转变到驱动商业成果，而且 DevOps 的文化能够通过自动化和强大的协作加速这些成果，来自 CYBRIC 的首席技术官和联合创始人迈克·凯尔说道。

事实上，这是一个强烈的趋势，贯穿这些新“规则”，在 DevOps 时代走在前沿。

“促进创新并且鼓励团队成员去聪明的冒险是 DevOps 文化的一个关键部分，IT 领导者们需要在一个持续的基础上清楚的和他们交流”，凯尔说道。

“一个高效的 IT 领导者需要比以往任何时候都要积极的参与到业务中去，”来自 West Monroe Partners 的性能服务部门的主任埃文说道，“每年或季度回顾的日子一去不复返了——你需要欢迎每两周一次的挤压整理，你需要有在年度水平上的思考战略能力，在冲刺阶段的互动能力，在商业期望满足时将会被给予一定的奖励。”

5、 改变妨碍 DevOps 目标的任何事情

虽然 DevOps 的老兵们普遍认为 DevOps 更多的是一种文化而不是技术，成功取决于通过正确的过程和工具激活文化。当你声称自己的部门是一个 DevOps 商店却拒绝对进程或技术做必要的改变，这就是你买了辆法拉利却使用了用了 20 年的引擎，每次转动钥匙都会冒烟。

展览 A： 自动化。这是 DevOps 成功的重要并行策略。

“IT 领导者需要重点强调自动化，”卡伦德说，“这将是 DevOps 的前期投资，但是如果没有它，DevOps 将会很容易被低效吞噬，而且将会无法完整交付。”

自动化是基石，但改变不止于此。

“领导者们需要推动自动化、监控和持续交付过程。这意着对现有的实践、过程、团队架构以及规则的很多改变，” 德里克说。“领导者们需要改变一切会阻碍团队去实现完全自动化的因素。”

6、 重新思考团队架构和能力指标

当你想改变时……如果你桌面上的组织结构图和你过去大部分时候嵌入的名字都是一样的，那么你是时候该考虑改革了。

“在这个 DevOps 的新时代文化中，IT 执行者需要采取一个全新的方法来组织架构。”凯尔说，“消除组织的边界限制，它会阻碍团队间的合作，允许团队自我组织、敏捷管理。”

凯尔告诉我们在 DevOps 时代，这种反思也应该拓展应用到其他领域，包括你怎样衡量个人或者团队的成功，甚至是你和人们的互动。

“根据业务成果和总体的积极影响来衡量主动性，”凯尔建议。“最后，我认为管理中最重要的一个方面是：有同理心。”

注意很容易收集的到测量值不是 DevOps 真正的指标，[Red Hat] 的技术专家戈登·哈夫写到，“DevOps 应该把指标以某种形式和商业成果绑定在一起”，他指出，“你可能并不真正在乎开发者些了多少代码，是否有一台服务器在深夜硬件损坏，或者是你的测试是多么的全面。你甚至都不直接关注你的网站的响应情况或者是你更新的速度。但是你要注意的是这些指标可能和顾客放弃购物车去竞争对手那里有关，”参考他的文章，[DevOps 指标：你在测量什么？]

7、 丢弃传统的智慧

如果 DevOps 时代要求关于 IT 领导能力的新的思考方式，那么也就意味着一些旧的方法要被淘汰。但是是哪些呢？

“说实话，是全部”，凯尔说道，“要摆脱‘因为我们一直都是以这种方法做事的’的心态。过渡到 DevOps 文化是一种彻底的思维模式的转变，不是对瀑布式的过去和变革委员会的一些细微改变。”

事实上，IT 领导者们认识到真正的变革要求的不只是对旧方法的小小接触。它更多的是要求对之前的进程或者策略的一个重新启动。

West Monroe Partners 的卡伦德分享了一个阻碍 DevOps 的领导力的例子：未能拥抱 IT 混合模型和现代的基础架构比如说容器和微服务。

“我所看到的一个大的规则就是架构整合，或者认为在一个同质的环境下长期的维护会更便宜，”卡伦德说。

via: https://enterprisersproject.com/article/2018/1/7-leadership-rules-devops-age

作者：Kevin Casey 译者：FelixYFZ 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

DevSecOps 也许不是一个优雅的词汇，但是其结果很吸引人：更强的安全、提前出现在开发周期中。来看看一个 IT 领导与 Meltdown 的拼搏。

如果 DevOps 最终是关于创造更好的软件，那也就意味着是更安全的软件。

而到了术语 “DevSecOps”，就像任何其他 IT 术语一样，DevSecOps —— 一个更成熟的 DevOps 的后代 ——可能容易受到炒作和盗用。但这个术语对那些拥抱了 DevOps 文化的领导者们来说具有重要的意义，并且其实践和工具可以帮助他们实现其承诺。

说道这里：“DevSecOps”是什么意思？

“DevSecOps 是开发、安全、运营的混合，”来自 Datical 的首席技术官和联合创始人 Robert 说。“这提醒我们，对我们的应用程序来说安全和创建并部署应用到生产中一样重要。”

想阅读其他首席技术官的 DevOps 文章吗？查阅我们丰富的资源，[DevOps：IT 领导者指南]

向非技术人员解释 DevSecOps 的一个简单的方法是：它是指将安全有意并提前加入到开发过程中。

“安全团队从历史上一直都被孤立于开发团队——每个团队在 IT 的不同领域都发展了很强的专业能力”，来自红帽安全策的专家 Kirsten 最近告诉我们。“不需要这样，非常关注安全也关注他们通过软件来兑现商业价值的能力的企业正在寻找能够在应用开发生命周期中加入安全的方法。他们通过在整个 CI/CD 管道中集成安全实践、工具和自动化来采用 DevSecOps。”

“为了能够做的更好，他们正在整合他们的团队——专业的安全人员从开始设计到部署到生产中都融入到了开发团队中了，”她说，“双方都收获了价值——每个团队都拓展了他们的技能和基础知识，使他们自己都成更有价值的技术人员。 DevOps 做的很正确——或者说 DevSecOps——提高了 IT 的安全性。”

IT 团队比任何以往都要求要快速频繁的交付服务。DevOps 在某种程度上可以成为一个很棒的推动者，因为它能够消除开发和运营之间通常遇到的一些摩擦，运营一直被排挤在整个过程之外直到要部署的时候，开发者把代码随便一放之后就不再去管理，他们承担更少的基础架构的责任。那种孤立的方法引起了很多问题，委婉的说，在数字时代，如果将安全孤立起来同样的情况也会发生。

“我们已经采用了 DevOps，因为它已经被证明通过移除开发和运营之间的阻碍来提高 IT 的绩效，”Reevess 说，“就像我们不应该在开发周期要结束时才加入运营，我们不应该在快要结束时才加入安全。”

为什么 DevSecOps 必然出现

或许会把 DevSecOps 看作是另一个时髦词，但对于安全意识很强的IT领导者来说，它是一个实质性的术语：在软件开发管道中安全必须是第一层面的要素，而不是部署前的最后一步的螺栓，或者更糟的是，作为一个团队只有当一个实际的事故发生的时候安全人员才会被重用争抢。

“DevSecOps 不只是一个时髦的术语——因为多种原因它是现在和未来 IT 将呈现的状态”，来自 [Sumo Logic] 的安全和合规副总裁 George 说道，“最重要的好处是将安全融入到开发和运营当中开提供保护的能力”

此外，DevSecOps 的出现可能是 DevOps 自身逐渐成熟并扎根于 IT 之中的一个征兆。

“企业中的 DevOps 文化已成定局，而且那意味着开发者们正以不断增长的速度交付功能和更新，特别是自我管理的组织会对合作和衡量的结果更加满意”，来自 [CYBRIC] 的首席技术官和联合创始人 Mike 说道。

在实施 DevOps 的同时继续保留原有安全措施的团队和公司，随着他们继续部署的更快更频繁可能正在经历越来越多的安全管理风险上的痛苦。

“现在的手工的安全测试方法会继续远远被甩在后面。”

“如今，手动的安全测试方法正被甩得越来越远，利用自动化和协作将安全测试转移到软件开发生命周期中，因此推动 DevSecOps 的文化是 IT 领导者们为增加整体的灵活性提供安全保证的唯一途径”，Kail 说。

转移安全测试也使开发者受益：他们能够在开放的较早的阶段验证并解决潜在的问题——这样很少需要或者甚至不需要安全人员的介入，而不是在一个新的服务或者更新部署之前在他们的代码中发现一个明显的漏洞。

“做的正确，DevSecOps 能够将安全融入到开发生命周期中，允许开发者们在没有安全中断的情况下更加快速容易的保证他们应用的安全”，来自 SAS 的首席信息安全员 Wilson 说道。

Wilson 指出静态（SAST）和源组合分析（SCA）工具，集成到团队的持续交付管道中，作为有用的技术通过给予开发者关于他们的代码中的潜在问题和第三方依赖中的漏洞的反馈来使之逐渐成为可能。

“因此，开发者们能够主动和迭代的缓解应用安全的问题，然后在不需要安全人员介入的情况下重新进行安全扫描。” Wilson 说。他同时指出 DevSecOps 能够帮助开发者简化更新和打补丁。

DevSecOps 并不意味着你不再需要安全组的意见了，就如同 DevOps 并不意味着你不再需要基础架构专家；它只是帮助你减少在生产中发现缺陷的可能性，或者减少导致降低部署速度的阻碍，因为缺陷已经在开发周期中被发现解决了。

“如果他们有问题或者需要帮助，我们就在这儿，但是因为已经给了开发者他们需要的保护他们应用安全的工具，我们很少在一个深入的测试中发现一个导致中断的问题，”Wilson 说道。

DevSecOps 遇到 Meltdown

Sumo Locic 的 Gerchow 向我们分享了一个在运转中的 DevSecOps 文化的一个及时案例：当最近 [Meltdown 和 Spectre] 的消息传来的时候，团队的 DevSecOps 方法使得有了一个快速的响应来减轻风险，没有任何的通知去打扰内部或者外部的顾客，Gerchow 所说的这点对原生云、高监管的公司来说特别的重要。

第一步：Gerchow 的小型安全团队都具有一定的开发能力，能够通过 Slack 和它的主要云供应商协同工作来确保它的基础架构能够在 24 小时之内完成修复。

“接着我的团队立即开始进行系统级的修复，实现终端客户的零停机时间，不需要去开工单给工程师，如果那样那意味着你需要等待很长的变更过程。所有的变更都是通过 Slack 的自动 jira 票据进行，通过我们的日志监控和分析解决方案”，Gerchow 解释道。

在本质上，它听起来非常像 DevOps 文化，匹配正确的人员、过程和工具，但它明确的将安全作为文化中的一部分进行了混合。

“在传统的环境中，这将花费数周或数月的停机时间来处理，因为开发、运维和安全三者是相互独立的”，Gerchow 说道，“通过一个 DevSecOps 的过程和习惯，终端用户可以通过简单的沟通和当日修复获得无缝的体验。”

via: https://enterprisersproject.com/article/2018/1/why-devsecops-matters-it-leaders

作者：Kevin Casey 译者：FelixYFZ 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

自动化专家分享了一点对 自动化不远的将来的看法。请将这些保留在你的视线之内。

我们最近讨论了 推动 IT 自动化的因素，可以看到当前趋势正在增长，以及那些给刚开始使用自动化部分流程的组织的 有用的技巧 。

噢，我们也分享了如何在贵公司进行自动化的案例及 长期成功的关键的专家建议。

现在，只有一个问题：自动化的下一步是什么? 我们邀请一系列专家分享一下 自动化不远的将来的看法。 以下是他们建议 IT 领域领导需密切关注的六大趋势。

1、 机器学习的成熟

对于关于 机器学习（与“自我学习系统”相似的定义）的讨论，对于绝大多数组织的项目来说，实际执行起来它仍然为时过早。但预计这将发生变化，机器学习将在下一次 IT 自动化浪潮中将扮演着至关重要的角色。

Advanced Systems Concepts, Inc. 公司的工程总监 Mehul Amin 指出机器学习是 IT 自动化下一个关键增长领域之一。

“随着数据化的发展，自动化软件理应可以自我决策，否则这就是开发人员的责任了”，Amin 说。 “例如，开发者构建了需要执行的内容，但通过使用来自系统内部分析的软件，可以确定执行该流程的最佳系统。”

假设将这个系统延伸到其他地方中。Amin 指出，机器学习可以使自动化系统在必要的时候提供额外的资源，以需要满足时间线或 SLA，同样在不需要资源以及其他的可能性的时候退出。

显然不只有 Amin 一个人这样认为。

“IT 自动化正在走向自我学习的方向” ，Sungard Availability Services 公司首席架构师 Kiran Chitturi 表示，“系统将会能测试和监控自己，加强业务流程和软件交付能力。”

Chitturi 指出自动化测试就是个例子。脚本测试已经被广泛采用，但很快这些自动化测试流程将会更容易学习，更快发展，例如开发出新的代码或将更为广泛地影响生产环境。

2、 人工智能催生的自动化

上述原则同样适合与相关的（但是独立的） 人工智能的领域。根据对人工智能的定义，机器学习在短时间内可能会对 IT 领域产生巨大的影响（并且我们可能会看到这两个领域的许多重叠的定义和理解）。假定新兴的人工智能技术将也会产生新的自动化机会。

SolarWinds 公司技术负责人 Patrick Hubbard 说，“人工智能和机器学习的整合普遍被认为对未来几年的商业成功起至关重要的作用。”

3、 这并不意味着不再需要人力

让我们试着安慰一下那些不知所措的人：前两种趋势并不一定意味着我们将失去工作。

这很可能意味着各种角色的改变，以及全新角色的创造。

但是在可预见的将来，至少，你不必需要对机器人鞠躬。

“一台机器只能运行在给定的环境变量中——它不能选择包含新的变量，在今天只有人类可以这样做，” Hubbard 解释说。“但是，对于 IT 专业人员来说，这将需要培养 AI 和自动化技能，如对程序设计、编程、管理人工智能和机器学习功能算法的基本理解，以及用强大的安全状态面对更复杂的网络攻击。”

Hubbard 分享一些新的工具或功能例子，例如支持人工智能的安全软件或机器学习的应用程序，这些应用程序可以远程发现石油管道中的维护需求。两者都可以提高效益和效果，自然不会代替需要信息安全或管道维护的人员。

“许多新功能仍需要人工监控，”Hubbard 说。“例如，为了让机器确定一些‘预测’是否可能成为‘规律’，人为的管理是必要的。”

即使你把机器学习和 AI 先放在一边，看待一般的 IT 自动化，同样原理也是成立的，尤其是在软件开发生命周期中。

Juniper Networks 公司自动化首席架构师 Matthew Oswalt ，指出 IT 自动化增长的根本原因是它通过减少操作基础设施所需的人工工作量来创造直接价值。

在代码上，操作工程师可以使用事件驱动的自动化提前定义他们的工作流程，而不是在凌晨 3 点来应对基础设施的问题。

“它也将操作工作流程作为代码而不再是容易过时的文档或系统知识阶段，”Oswalt 解释说。“操作人员仍然需要在[自动化]工具响应事件方面后发挥积极作用。采用自动化的下一个阶段是建立一个能够跨 IT 频谱识别发生的有趣事件的系统，并以自主方式进行响应。在代码上，操作工程师可以使用事件驱动的自动化提前定义他们的工作流程，而不是在凌晨 3 点来应对基础设施的问题。他们可以依靠这个系统在任何时候以同样的方式作出回应。”

4、 对自动化的焦虑将会减少

SolarWinds 公司的 Hubbard 指出，“自动化”一词本身就产生大量的不确定性和担忧，不仅仅是在 IT 领域，而且是跨专业领域，他说这种担忧是合理的。但一些随之而来的担忧可能被夸大了，甚至与科技产业本身共存。现实可能实际上是这方面的镇静力：当自动化的实际实施和实践帮助人们认识到这个列表中的第 3 项时，我们将看到第 4 项的出现。

“今年我们可能会看到对自动化焦虑的减少，更多的组织开始接受人工智能和机器学习作为增加现有人力资源的一种方式，”Hubbard 说。“自动化历史上为更多的工作创造了空间，通过降低成本和时间来完成较小任务，并将劳动力重新集中到无法自动化并需要人力的事情上。人工智能和机器学习也是如此。”

自动化还将减少令 IT 领导者神经紧张的一些焦虑：安全。正如红帽公司首席架构师 Matt Smith 最近指出的那样，自动化将越来越多地帮助 IT 部门降低与维护任务相关的安全风险。

他的建议是：“首先在维护活动期间记录和自动化 IT 资产之间的交互。通过依靠自动化，您不仅可以消除之前需要大量手动操作和手术技巧的任务，还可以降低人为错误的风险，并展示当您的 IT 组织采纳变更和新工作方法时可能发生的情况。最终，这将迅速减少对应用安全补丁的抵制。而且它还可以帮助您的企业在下一次重大安全事件中摆脱头条新闻。”

* 阅读全文: [12个企业安全坏习惯要打破。 ] *

5、 脚本和自动化工具将持续发展

许多组织看到了增加自动化的第一步，通常以脚本或自动化工具（有时称为配置管理工具）的形式作为“早期”工作。

但是随着各种自动化技术的使用，对这些工具的观点也在不断发展。

DataVision 首席运营官 Mark Abolafia 表示：“数据中心环境中存在很多重复性过程，容易出现人为错误，Ansible 等技术有助于缓解这些问题。“通过 Ansible ，人们可以为一组操作编写特定的步骤，并输入不同的变量，例如地址等，使过去长时间的过程链实现自动化，而这些过程以前都需要人为触摸和更长的交付时间。”

想了解更多关于 Ansible 这个方面的知识吗？阅读相关文章：[使用 Ansible 时的成功秘诀。 ]

另一个因素是：工具本身将继续变得更先进。

“使用先进的 IT 自动化工具，开发人员将能够在更短的时间内构建和自动化工作流程，减少易出错的编码，” ASCI 公司的 Amin 说。“这些工具包括预先构建的、预先测试过的拖放式集成，API 作业，丰富的变量使用，参考功能和对象修订历史记录。”

6、 自动化开创了新的指标机会

正如我们在此前所说的那样，IT 自动化不是万能的。它不会修复被破坏的流程，或者以其他方式为您的组织提供全面的灵丹妙药。这也是持续不断的：自动化并不排除衡量性能的必要性。

参见我们的相关文章 [DevOps 指标：你在衡量什么重要吗？ ]

实际上，自动化应该打开了新的机会。

Janeiro Digital 公司架构师总裁 Josh Collins 说，“随着越来越多的开发活动 —— 源代码管理、DevOps 管道、工作项目跟踪等转向 API 驱动的平台，将这些原始数据拼接在一起以描绘组织效率提升的机会和图景”。

Collins 认为这是一种可能的新型“开发组织度量指标”。但不要误认为这意味着机器和算法可以突然预测 IT 所做的一切。

“无论是衡量个人资源还是整体团队，这些指标都可以很强大 —— 但应该用大量的背景来衡量。”Collins 说，“将这些数据用于高层次趋势并确认定性观察 —— 而不是临床评级你的团队。”

想要更多这样知识， IT 领导者？注册我们的每周电子邮件通讯。

via: https://enterprisersproject.com/article/2018/3/what-s-next-it-automation-6-trends-watch

作者：Kevin Casey 译者：MZqk 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

想要你的整个团队都登上 IT 自动化之旅吗？ IT 执行者们分享了他们的战略。

在任何重要的项目或主动变更刚开始的时候，IT 的管理者在前进的道路上面临着普遍的抉择。

第一条路径看上去是提供了一个从 A 到 B 的最短路径：简单的把项目强制分配给每个人去执行，本质来说就是你要么按照要求去做要么就不要做了。

第二条路径可能看上去会不是很直接，因为要通过这条路径你需要花时间去解释项目背后的策略以及原因。你会沿着这条路线设置停靠站点而不是从起点到终点的马拉松：“这就是我们正在做的 —— 和为什么我们这么做。”

猜想一下哪条路径会赢得更好的结果？

如果你选的是路径 2，你肯定是以前都经历过这两条路径——而且经历了第一次的结局。让人们参与到重大变革中总会是最明智的选择。

IT 领导者也知道重大的变革总会带来严重的恐慌、怀疑，和其他的挑战。IT 自动化确实是很正确的改变。这个术语对某些人来说是很可怕的，而且容易被曲解。帮助人们理解你的公司需要 IT 自动化的必要性的原因以及如何去实现是达到你的目标和策略的重要步骤。

阅读我们的相关文章，[IT自动化最佳实践：持久成功的7个关键点。]

考虑到这一点，我们咨询了许多 IT 管理者关于如何在你的组织中实现 IT 自动化。

1、向人们展示它的优点

我们要面对的一点事实是：自我利益和自我保护是本能。利用人们的这种本能是一个吸引他们的好方法：向他们展示自动化策略将如何让他们和他们的工作获益。自动化将会是软件管道中的一个特定过程意味着将会减少在半夜呼叫团队同事来解决故障？它将能让一些人丢弃技术含量低的技能，用更有策略、高效的有序工作代替手工作业，这将会帮助他们的职业生涯更进一步？

“向他们传达他们能得到什么好处，自动化将会如何让他们的客户和公司受益，”来自 ADP 全球首席技术官 vipual Nagrath 的建议。“将现在的状态和未来光明的未来进行对比，展现公司将会变得如何稳定，敏捷，高效和安全。”

这样的方法同样适用于 IT 领域之外的其他领域；只要在向非技术领域的股东们解读利益的时候解释清楚一些术语即可，Nagrath 说道。

设置好前后的情景是一个不错的帮助人们理解的更透彻的故事机。

“你要描述一幅人们能够联想到的当前状态的画面，” Nagrath 说。“描述现在是什么工作，但也要重点强调是什么导致团队的工作效率不够敏捷。”然后再阐释自动化过程将如何提高现在的状态。

2、将自动化和特定的商业目标绑定在一起

一个强有力的案列的一部分要确保人们理解你不只是在追逐潮流趋势。如果只是为了自动化而自动化，人们会很快察觉到进而会更加抵制的——也许在 IT 界更是如此。

“自动化需要商业需求的驱动，例如收入和运营开销，” Cyxtera的副总裁和首席信息安全官 David Emerson 说道。“没有自动化的努力是自我辩护的，而且任何技术专长都不应该被当做一种手段，除非它是公司的一项核心能力。”

像 Nagrath 一样，Emerson 建议将达到自动化的商业目标和奖励措施挂钩，用迭代式的循序渐进的方式推进这些目标和相关的激励措施。

3、 将自动化计划分解为可管理的条目

即使你的自动化策略字面上是“一切都自动化”，对大多数组织来说那也是很艰难的，而且可能是没有灵活性的。你需要制定一个强有力的方案，将自动化目标分解为可管理的目标计划。而且这将能够创造很大的灵活性来适应之后漫长的道路。

“当制定一个自动化方案的时候，我建议详细的阐明推进自动化进程的奖励措施，而且允许迭代朝着目标前进来介绍和证明利益处于一个低风险水平，”Emerson 说道。

GA Connector 的创始人 Sergey Zuev 分享了一个为什么自动化如此重要的快节奏体验的报告——它将怎样为你的策略建立一个强壮持久的论点。Zuevz 应该知道：他的公司的自动化工具将公司的客户关系应用数据导入谷歌分析。但实际上是公司的内部经验使顾客培训进程自动化从而出现了一个闪耀的时刻。

“起初， 我们曾尝试去建立整个培训机制，结果这个项目搁浅了好几个月，”Zuev 说道。“认识到这将无法继续下去之后，我们决定挑选其中的一个能够有巨大的时效的领域，而且立即启动。结果我们只用了一周就实现了其中的电子邮件序列的目标，而且我们已经从被亵渎的体力劳动中获益。”

4、 出售主要部分也有好处

循序渐进的方法并不会阻碍构建一个宏伟的蓝图。就像以个人或者团队的水平来制定方案是一个好主意，帮助人们理解全公司的利益也是一个不错的主意。

“如果我们能够加速达到商业需求所需的时间，那么一切质疑将会平息。”

AHEAD 的首席技术官 Eric Kaplan 赞同通过小范围的胜利来展示自动化的价值是一个赢得人心的聪明策略。但是那些所谓的“小的”的价值揭示能够帮助你提高人们的整体形象。Kaplan 指出个人和组织间的价值是每个人都可以容易联系到的领域。

“最能展现的地方就是你能够节约多少时间，”Kaaplan 说。“如果我们能够加速达到商业需求所需的时间，那么一切质疑将会消失。”

时间和可伸缩性是业务和 IT 同事的强大优势，都复制业务的增长，可以把握。

“自动化的结果是灵活伸缩的——每个人只需较少的努力就能保持和改善你的 IT 环境”，红帽的全球服务副总裁 John Allessio 最近提到。“如果增加人力是提升你的商业的唯一途径，那么灵活伸缩就是白日梦。自动化减少了你的人力需求而且提供了 IT 演进所需的灵活性和韧性。”(详细内容请参考他的文章，[DevOps 团队对 CIO 的真正需求是什么。])

5、 推广你的成果。

在你自动化策略的开始时，你可能是在目标和要达到目标的预期利益上制定方案。但随着你的自动化策略的不断演进，没有什么能够比现实中的实际结果令人信服。

“眼见为实，”ADP 的首席技术官 Nagrath 说。“没有什么比追踪记录能够平息质疑。”

那意味着，不仅仅要达到你的目标，还要准时的完成——这是迭代的循序渐进的方法论的另一个不错的解释。

而量化的结果如比利润的提高或者成本的节省可以大声宣扬出来，Nagrath 建议他的 IT 领导者同行在讲述你们的自动化故事的时候不要仅仅止步于此。

为自动化提供案例也是一个定性的讨论，通过它我们能够促进问题的预防，归总商业的连续性，减伤失败或错误，而且能够在他们处理更有价值的任务时承担更多的责任。

via: https://enterprisersproject.com/article/2018/1/how-make-case-it-automation

作者：Kevin Casey 译者：FelixYFZ 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

专家们权衡了 DevOps 团队最近会有何期望。

“DevOps” 一词通常认为是来源于 这篇 2008 年关于敏捷基础设施和运营的讲演中。现在的 IT 词汇中，它无处不在，这个“混搭”的词汇出现还不到 10 年：我们还在研究它在 IT 中更现代化的工作方法。

诚然，多年来一直在 “从事 DevOps” 的人积累了丰富的知识。但是大多数的 DevOps 环境 —— 人与 文化 、流程与方法、工具与技术的融合 —— 还远远没有成熟。

更多的变化即将到来。Robert Reeves 说 “DevOps 是一个过程，一种算法”，他是 Datical 的 CTO， “它的绝对目标就是随着时间进行改变和演进”，这就是重点。

那我们预计接下来会发生什么呢？这里有一些专家们观察到的重要趋势。

1、 预计 DevOps、容器、以及微服务之间的相互依赖会增强

驱动 DevOps 发展的文化本身可能会演进。当然，DevOps 仍然将在根本上摧毁传统的 IT 孤岛和瓶颈，但这样做的理由可能会变得更加急迫。证据 A & B： 对容器和微服务的兴趣 与日俱增。这个技术组合很强大、可连续扩展、与规划和 持续进行的管理配合最佳。

Arvind Soni 说 “影响 DevOps 的其中一个主要因素是向微服务转变”，他是 Netsil 的产品副总裁，补充道，容器和业务流程，使开发者打包和交付的速度越来越快。DevOps 团队的任务可能是帮助去加速打包并管理越来越复杂的微服务弹性架构。

2、 预计 ”安全网“ 更少

DevOps 使团队可以更快更敏捷地去构建软件，部署速度也更快更频繁、同时还能提升软件质量和稳定性。但是好的 IT 领导通常都不会忽视管理风险，因此，早期大量的 DevOps 迭代都是使用了安全防护 —— 从后备的不重要业务开始的。为了实现更快的速度和敏捷性，越来越多的团队将抛弃他们的 ”辅助轮“（LCTT 译注：意思说减少了安全防护措施）。

Nic Grange 说 “随着团队的成熟，他们决定不再需要一些早期增加的安全 ‘防护栏’ 了”，他是 Retriever Communications 的 CTO。Grange 给出了一个阶段展示的服务器的示例：随着 DevOps 团队的成熟，他们决定不再需要阶段展示的服务器了，尤其是他们很少在试生产环境中发现问题。（Grange 指出，这一举措对于缺乏 DevOps 经验的团队来说，不可轻易效仿）

Grange 说 “这个团队可能在监视和发现并解决生产系统中出现的问题的能力上有足够的信心”，“部署过程和测试阶段，如果没有任何证据证明它的价值，那么它可能会把整个进度拖慢”。

3、 预计 DevOps 将在其它领域大面积展开

DevOps 将两个传统的 IT 部门（开发和运营）结合的更紧密。越来越多的公司看到了这种结合的好处，这种文化可能会传播开来。这种情况在一些组织中已经出现，在 “DevSecOps” 一词越来越多出现的情况下，它反映出了在软件开发周期中有意地、越来越早地包含了安全性。

Derek Weeks 说 “DevSecOps 不仅是一个工具，它是将安全思维更早地集成到开发实践中”，它是 Sonatype 的副总裁和 DevOps 拥挤者。

Red Hat 的安全策略师 Kirsten Newcomer 说，这种做法并不是一个技术挑战，而是一个文化挑战。

Newcomer 说 “从历史来看，安全团队都是从开发团队中分离出来的 —— 每个团队在它们不同的 IT 领域中形成了各自的专长” ，“它并不需要这种方法。每个关心安全性的企业也关心他们通过软件快速交付业务价值的能力，这些企业正在寻找方法，将安全放进应用程序的开发周期中。它们采用 DevSecOps 通过 CI/CD 流水线去集成安全实践、工具和自动化。为了做的更好，他们整合他们的团队 —— 将安全专家整合到应用程序开发团队中，参与到从设计到产品部署的全过程中。这种做法使双方都看到了价值 —— 每个团队都扩充了它们的技能和知识，使他们成为更有价值的技术专家。DevOps 做对了 —— 或者说是 DevSecOps —— 提升了 IT 安全性。”

除了安全以外，还可以让 DevOps 扩展到其它领域，比如数据库团队、QA，甚至是 IT 以外的潜在领域。

Datical 的 Reeves 说 “这是一件非常 DevOps 化的事情：发现相互掣肘的地方并解决它们”，“对于以前采用 DevOps 的企业来说，安全和数据库是他们面临的最大瓶颈。”

4、 预计 ROI 将会增加

Eric Schabell 说，“由于公司深入推进他们的 DevOps 工作，IT 团队在方法、流程、容器和微服务方面的投资将得到更多的回报。” 他是 Red Hat 的全球技术传播总监，Schabell 说 “‘圣杯’将移动的更快、完成的更多、并且变得更灵活。由于这些组件找到了更宽阔的天地，组织在应用程序中更有归属感时，结果就会出现。”

“每当新兴技术获得我们的关注时，任何事都有一个令人兴奋的学习曲线，但当认识到它应用很困难的时候，同时也会经历一个从兴奋到幻灭的低谷。最终，我们将开始看到从低谷中爬出来，并收获到应用 DevOps、容器、和微服务的好处。”

5、 预计成功的指标将持续演进

Mike Kail 说 “我相信 DevOps 文化的两个核心原则 —— 自动化和可衡量是从来不会变的”，它是 CYBRIC 的 CTO，也是 Yahoo 前 CIO。“总是有办法去自动化一个任务，或者提升一个已经自动化的解决方案，而随着时间的推移，重要的事情是测量可能的变化和扩展。这个成熟的过程是一个永不停步的旅行，而不是一个目的地或者已完成的任务。”

在 DevOps 的精神中，成熟和学习也与协作者和分享精神有关。Kail 认为，对于敏捷方法和 DevOps 文化来说，它仍然为时尚早，这意味着它们还有足够的增长空间。

Kail 说 “随着越来越多的成熟组织持续去测量可控指标，我相信（希望） —— 这些经验应该被广泛的分享，以便我们去学习并改善它们。”

作为 Red Hat 技术传播专家，Gordon Haff 最近注意到，组织使用业务成果相关的因素去改善他们的 DevOps 指标的工作越来越困难。 Haff 写道 “你或许并不真正关心你的开发者写了多少行代码、服务器是否在一夜之间出现了硬件故障、或者你的测试覆盖面是否全面”。事实上，你可能并不直接关心你的网站的响应速度和更新快慢。但是你要注意的是，这些指标可能与消费者放弃购物车或者转到你的竞争对手那里有关。”

与业务成果相关的一些 DevOps 指标的例子包括，消费者交易金额（作为消费者花销统计的指标）和净推荐值（消费者推荐公司产品和服务的意愿）。关于这个主题更多的内容，请查看这篇完整的文章—— DevOps 指标：你是否测量了重要的东西。

唯一不变的就是改变

顺利说一句，如果你希望这件事一蹴而就，那你就要倒霉了。

Reeves 说 “如果你认为今天发布非常快，那你就什么也没有看到”，“这就是为什么要让相关者包括数据库团队进入到 DevOps 中的重要原因。因为今天这两组人员的冲突会随着发布速度的提升而呈指数级增长。”

via: https://enterprisersproject.com/article/2017/10/what-s-next-devops-5-trends-watch

作者：Kevin Casey 译者：qhwdw 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

微服务与容器天生匹配，但是你需要避开一些常见的陷阱。

因为微服务和容器是 天生的“一对”，所以一起来使用它们，似乎也就不会有什么问题。当我们将这对“天作之合”投入到生产系统后，你就会发现，随着你的 IT 基础的提升，等待你的将是大幅上升的成本。是不是这样的？

（让我们等一下，等人们笑声过去）

是的，很遗憾，这并不是你所希望的结果。虽然这两种技术的组合是非常强大的，但是，如果没有很好的规划和适配，它们并不能发挥出强大的性能来。在前面的文章中，我们整理了如果你想 使用它们你应该掌握的知识。但是，那些都是组织在容器中使用微服务时所遇到的常见问题。

事先了解这些可能出现的问题，能够帮你避免这些问题，为你的成功奠定更坚实的基础。

微服务和容器技术的出现是基于组织的需要、知识、资源等等更多的现实的要求。Mac Browning 说，“他们最常犯的一个 [错误] 是试图一次就想‘搞定’一切”，他是 DigitalOcean 的工程部经理。“而真正需要面对的问题是，你的公司应该采用什么样的容器和微服务。”

努力向你的老板和同事去解释什么是微服务？阅读我们的入门读本[如何简单明了地解释微服务。]

Browning 和其他的 IT 专业人员分享了他们遇到的，在组织中使用容器化微服务时的五个陷阱，特别是在他们的生产系统生命周期的早期时候。在你的组织中需要去部署微服务和容器时，了解这些知识，将有助于你去评估微服务和容器化的部署策略。

1、 在部署微服务和容器化上，试图同时从零开始

如果你刚开始从完全的单例应用开始改变，或者如果你的组织在微服务和容器化上还没有足够的知识储备，那么，请记住：微服务和容器化并不是拴在一起、不可分别部署的。这就意味着，你可以发挥你公司内部专家的技术特长，先从部署其中的一个开始。Sungard Availability Services]5 的资深 CTO 架构师 Kevin McGrath 建议，通过首先使用容器化来为你的团队建立知识和技能储备，通过对现有应用或者新应用进行容器化部署，接着再将它们迁移到微服务架构，这样才能最终感受到它们的优势所在。

McGrath 说，“微服务要想运行的很好，需要公司经过多年的反复迭代，这样才能实现快速部署和迁移”，“如果组织不能实现快速迁移，那么支持微服务将很困难。实现快速迁移，容器化可以帮助你，这样就不用担心业务整体停机”。

2、 从一个面向客户的或者关键的业务应用开始

对组织来说，一个相关陷阱恰恰就是从容器、微服务、或者两者同时起步：在尝试征服一片丛林中的雄狮之前，你应该先去征服处于食物链底端的一些小动物，以取得一些实践经验。

在你的学习过程中可以预期会有一些错误出现 —— 你是希望这些错误发生在面向客户的关键业务应用上，还是，仅对 IT 或者其他内部团队可见的低风险应用上？

DigitalOcean 的 Browning 说，“如果整个生态系统都是新的，为了获取一些微服务和容器方面的操作经验，那么，将它们先应用到影响面较低的区域，比如像你的持续集成系统或者内部工具，可能是一个低风险的做法。”你获得这方面的经验以后，当然会将这些技术应用到为客户提供服务的生产系统上。而现实情况是，不论你准备的如何周全，都不可避免会遇到问题，因此，需要提前为可能出现的问题制定应对之策。

3、 在没有合适的团队之前引入了太多的复杂性

由于微服务架构的弹性，它可能会产生复杂的管理需求。

作为 Red Hat 技术的狂热拥护者，Gordon Haff 最近写道，“一个符合 OCI 标准的容器运行时本身管理单个容器是很擅长的，但是，当你开始使用多个容器和容器化应用时，并将它们分解为成百上千个节点后，管理和编配它们将变得极为复杂。最终，你将需要回过头来将容器分组来提供服务 —— 比如，跨容器的网络、安全、测控”。

Haff 提示说，“幸运的是，由于容器是可移植的，并且，与之相关的管理栈也是可移植的”。“这时出现的编配技术，比如像 Kubernetes ，使得这种 IT 需求变得简单化了”（更多内容请查阅 Haff 的文章：容器化为编写应用带来的 5 个优势）。

另外，你需要合适的团队去做这些事情。如果你已经有 DevOps shop，那么，你可能比较适合做这种转换。因为，从一开始你已经聚集了相关技能的人才。

Mike Kavis 说，“随着时间的推移，部署了越来越多的服务，管理起来会变得很不方便”，他是 Cloud Technology Partners 的副总裁兼首席云架构设计师。他说，“在 DevOps 的关键过程中，确保各个领域的专家 —— 开发、测试、安全、运营等等 —— 全部都参与进来，并且在基于容器的微服务中，在构建、部署、运行、安全方面实现协作。”

4、 忽视重要的需求：自动化

除了具有一个合适的团队之外，那些在基于容器化的微服务部署比较成功的组织都倾向于以“实现尽可能多的自动化”来解决固有的复杂性。

Carlos Sanchez 说，“实现分布式架构并不容易，一些常见的挑战，像数据持久性、日志、排错等等，在微服务架构中都会变得很复杂”，他是 CloudBees 的资深软件工程师。根据定义，Sanchez 提到的分布式架构，随着业务的增长，将变成一个巨大无比的繁重的运营任务。“服务和组件的增殖，将使得运营自动化变成一项非常强烈的需求”。Sanchez 警告说。“手动管理将限制服务的规模”。

5、 随着时间的推移，微服务变得越来越臃肿

在一个容器中运行一个服务或者软件组件并不神奇。但是，这样做并不能证明你就一定在使用微服务。Manual Nedbal， ShieldX Networks 的 CTO，他警告说，IT 专业人员要确保，随着时间的推移，微服务仍然是微服务。

Nedbal 说，“随着时间的推移，一些软件组件积累了大量的代码和特性，将它们放在一个容器中将会产生并不需要的微服务，也不会带来相同的优势”，也就是说，“随着组件的变大，工程师需要找到合适的时机将它们再次分解”。

via: https://enterprisersproject.com/article/2017/9/using-microservices-containers-wisely-5-pitfalls-avoid

作者：Kevin Casey 译者：qhwdw 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出