通过我们听到很多关于DevOps如何改变现代软件开发的说法，但它可能是一把双刃剑。如果做得好，DevOps可以让软件团队以比以往更快的速度自信地交付软件;如果做得不好，团队会认为这只是另一个过程失败。软件团队的经理们努力工作以防止后者。
而不是管理团队专注于一个领域（开发），努力与另一个领域的团队（操作）保持关系，Devops环境的管理人员为单个团队提供指导。他们努力确保这些传统上敌人的角色在低应力但高产能力方面与客户满意为驱动因素。这个想法是使团队尽可能摩擦。
要了解更多关于这在现实世界中的工作，我们问道杰森普尔是新遗物高级软件工程经理，关于他如何给予新遗物移动监控团队为他们成功地继续他们的DevOps之旅提供指导和支持。
在团队成分，工作和沟通
新遗物：您的团队构建是什么以及您团队的构成是什么？
高级软件工程经理Jason Poole
杰森普尔：我的团队建立了新的遗物移动APM产品。我们为移动应用程序开发人员提供工具和UI，以监控他们的Android和iOS应用程序。
我们的团队有七个人，他们都是各自领域的专家。我们有站点可靠性工程师（SRES），Android和iOS代理商的专家我们支持和UI开发人员。虽然，但我们的目标是成为“t形截面的“尽可能让每个人都知道如何在我们堆栈的每个部分工作。如果有人休假或某些病假，我们不希望团队压力或努力停止努力。
新遗物：您的团队平衡功能如何，可靠性和以客户为中心的工作？
杰森：我们不断与我们的产品经理合作，以决定最重要的工作。我们在每周冲刺工作，并保持我们的MMFS（最低可营销特征）小，因此如果最重要的是更改的更改，我们可以快速转移以满足新的需求。作为工程经理，我与产品经理合作，平衡可靠性，并在每周划分的功能工作，以确保两个方面都被占了。
你的团队做什么样的可靠性工作?定期的可靠性工作如何增强您的DevOps文化?
杰森：我们的可靠性工作基于我们不想发生事件的想法。我们可以做些什么来积极避免事故？我们考虑了很多关于容量规划 - 我们如何扩展我们的主机或数据库？我们比较我们现在到来的地方我们想到的地方。我们还完成了很多工作来保持我们的依赖关系和图书馆。安全性同样的事情;我们确保将我们的主机和服务与所有最新的补丁保持联系。
我们的目标是掌握一切，这样我们以后就不会被咬到。这增强了我们的DevOps文化，因为我们都要对我们所做的可靠性工作负责，以保持我们的产品健康发展。
团队内部的沟通是如何运作的?团队如何与其他团队沟通?
杰森：我的团队中的沟通，我会说，很棒。因为我们能够一次专注于一个MMF，所以存在最小的上下文切换，大多数团队成员在同一时间内设置。
就与其他团队的互动来说，拥有T形工程师意味着来自团队的任何人通常能够与任何其他团队讨论我们的堆栈。在罕见的情况下，他们无法回答关于我们的堆栈的问题，他们至少知道团队专家是谁。
新遗物：你的团队是否有草皮战争？
杰森：[笑]。幸运的是没有。我们的想法都差不多了。该团队在这个DevOps模型中工作非常流畅。
新遗物：您是否必须帮助并鼓励他们采用或尝试新的流程或工作方式？
杰森：当我们第一次组队时项目的高档，我们让我们的工程师自助选择他们想要加入的团队，花了一段时间才能在蜂拥而至，这是我们七个人在同一件事上工作而不是七种不同的事情。他们表达的大部分不适都必须使用他们不熟悉的工具或堆栈的一部分。这基本上是他们的开发之旅，一旦我帮助他们迭代和改善过程，他们就会去参加比赛。
你是如何处理事后事件的?你有一种无可指责的文化吗?
杰森：我们对我们的后期有一种独特的方法。当我们需要持有一个时，我们没有一定的门槛，这是一个“肠道感觉”。它可能是因为事件非常严重，否则我们可能只是需要聚集在一起来谈论事情。
我们有一个“无名”的文化，但不一定标记它;相反，我们努力专注于团队信任。我们希望确保我们彼此持有对我们正在做的工作负责。
New Relic:团队的参与规则是什么?
杰森：事实上，我们尝试尽可能少的过程，但我们每隔一周都能追回我们可以决定改变事物的情况下。我们将每个Sprint致力于来自支持的分类传入请求，他们还悬挂了我的团队将在日常立场审查的故障单位。一旦问题进行了三次，我与我们的PM合作，决定它是如何优先考虑的。我提倡获得可靠性工作，但我们必须为团队花费时间的优先级，无论是ops如何相关与否。当请求来自其他工程团队时，我与我们的PM一起进行分类。这使得团队可以在没有中断的情况下工作。
作为一名工程经理，我认为这是一种“DevOps方式”的工作方式，但这也是一个简单的高功能团队。
论探索原则在实践中
New Relic:你们如何促进开发团队和运营团队成员之间的紧密合作?
杰森：我们尝试随时随地努力工作。我们的DEV或OPS专家总是有人与他们合作;你总是至少有一个合作伙伴。每个人都有努力分享信息，所以我们永远不必担心团队中的单一失败。你知道，我们都想消除巴士因子。(笑)如果有人被公共汽车击中，我们可以在没有他们的情况下继续。
新遗物：您的开发周期中的阶段是什么？一个周期有多长？
杰森：就像我说的，我们保持流程简单。我们有一个规划阶段，产品经理和设计师致力于我们的团队。然后我们有一个MMF开始分解和评估工作，然后直接进入开发阶段。我们的MMF开发周期为2到4周，当然，越短越好，灵活性越好。
我们的行业迅速变化，我们需要尽可能快地反应。如果我们客户正在使用更改的技术，我们也需要改变。如果一个关键功能弹出，我们希望尽快工作。短周期意味着我们可以快速改变和枢转。由于我们的冲刺持续了一个星期，我们必须等待枢转到其他一些工作的最长是7天。这适用于我们的MMFS，我们也可以让他们保持小，所以如果我们被要求改变课程，我们可以完成它们。
你多久提交一次代码/部署到生产环境?是开发还是登台?
杰森：我们根据需要部署到生产中。这一天可能是零次，第二天可能是五次。这取决于我们在做什么。我们的应用程序由几个服务组成，所以我们部署金丝雀这些服务比这更频繁地生产，也许是往往的三倍。我们甚至可以更频繁地部署到常规的摊位。
然而，我们很少部署我们的代理。这些代理进入客户应用程序，必须非常稳定。我们可能一个月发布一次。
新遗物：典型部署需要多长时间？你有没有把它们滚回来？
杰森：不同的服务会有不同。从我们决定部署到完成的时间通常不超过15分钟。对于一些棘手的服务，可能需要一个小时才能完全展开并完成负载的再平衡。我们正在更新我们的服务，所以这些时间总是在改进。
由于我们的金丝雀部署，我们不必经常回滚部署。大多数时候我们继续前进，如果有需要改变的东西，我们可以更改它并部署新版本。始终汇总鼓励我们与大型更改相反的增量变化。这就是我们如何继续尝试新事物 - 如果我们遇到问题，就会容易回滚。
团队使用什么自动化工具?
杰森：我们的构建和部署管道全部由名为Grand Central的内部工具管理，这些工具连接到我们的内部容器编排平台，称为集装箱结构，该平台托管大部分新的遗物生态系统。我们跑步詹金斯建立我们的代理商。我们运行自动化测试针对我们的UI调味料实验室，我们使用新的遗物合成纤维不断地验证端点。
新遗物：您有服务级目标，协议和指标吗？
杰森：我们确实有SLA。它是由一个更大的产品组织为我们定义的——4个9。99.99%的正常运行时间。
当然，这也取决于新的遗物生态系统的其他团队和部分。但我们确实使用了New Relic的警报主动寻找可能导致失败的趋势前它们变成了真实的事件。等待失败的发生意味着你已经太晚了。
新遗物：如何监视应用程序的性能？
杰森：这是一个巨大的问题！
我们测量UI组件的性能新的遗物浏览器，特别关注整个页面加载所需的时间。对于组成我们的应用程序的服务，我们用新遗物APM比如，密切关注服务响应请求需要多长时间，以及观察可能会减慢请求速度的任何因素。我们还使用composite检查API端点的响应时间。我们的服务在不断发展，因为我们要把它们分解成更多离散的单元。正因为如此，我们不断改变我们的监控策略。
最后，对于我们的代理商来说，我们测量CPU和内存用法，以确保我们对客户的应用影响最小。
新遗物：您使用什么其他监控来帮助您满足您的Devops目标？
杰森：正如我所说，我们使用主动警报，但我们也有几个New Relic的见解仪表板让我们了解我们系统中发生的事情。主要是，我们专注于监控CPU使用率，服务器健康和数据流动Kafka.队列。我们还跟踪用户帐户以查看我们的客户与我们的服务互动的何时以及如何。
新遗物：从您的角度作为工程经理，对Devops团队健康的任何其他思考？
杰森：整个向DevOps的范式转变是我们在New Relic取得成功的基础，也改变了我们对创建软件的思考方式。我们的团队更健康，因为他们一起为相同的目标而努力，一起解决更棘手的问题，一起庆祝胜利。
当他们想要某些东西或出现问题时，仅在彼此互相思考，而不是管理默扣团队，而是仅在出现问题时互相思考，而是管理一个专注于提供客户价值的团队。管理像这样的团队是一个快乐 - 我们都分享了同样的愿景，并赋予了不仅做出我们的团队的决策，而是我们喜欢建造的产品。亚博最新版直播
准备衡量你的Devops旅程吗？
使用新的文物和我们的测量Devops成功的指南准备、激活和优化您的DevOps旅程将帮助您跟踪每一步，仔细考虑每一个决定，并增加成功的几率。
通过
通过