敏捷和 DevOps 方法是否可以应用于技术领域之外？ 更具体地说，我们可以将它们应用于体育运动吗？ 我决定通过分析敏捷和 DevOps 原则在我自己的公路自行车队中的应用来回答这些问题。
自行车是一项数据驱动的运动。在训练和比赛时，我们的自行车车把上安装的电脑会实时显示数据。 这些数据显示功率（瓦特）、心率（bpm）、步频（rpm）等等。
监控和分析这些数据使我们能够在自己的极限范围内工作，以确保我们在发挥最高能力的同时不会超负荷。 我们通过 30 秒、5 分钟和 20 分钟等时间段的测试来测量我们的极限。 这些测试的结果形成了特定的阈值，我们在这些阈值范围内工作，以最大限度地提高训练和比赛的效益。 我们可以在自行车电脑上设置自动警报，以警告我们是否过度劳累，或者我们可以盯着屏幕自行测量。
在一个成熟的 DevOps 环境中，我们致力于在服务级别进行监控，以了解使用情况、性能、环境、应用程序健康状况等等。 这不仅可以帮助我们找到问题； 它还允许我们在监控工具报告任何警报时，在我们的基础设施中设置自我修复协议。
我们将团队作为一个创业公司来运营，每个人都身兼数职。 我们以小的、松散耦合的单元运作； 每个人一起骑行，没有孤岛效应，但我们也有在训练期间展现出来的特长。 例如，爬坡手更擅长快速上坡，所以他们有时会一起工作，强大的冲刺手也会和冲刺手一起工作，等等。 关键是，我们不会将自己仅仅局限于这些职责——冲刺手仍然需要克服爬坡，而爬坡手仍然需要练习冲刺。 我们永远不知道什么时候我们需要顶替队友。 我们了解彼此的角色以及团队中每个人的重要性。
我们在实践中学习。 我们不能仅仅依赖团队中的一个人，即使他们是最强的。 假设 A 车手在终点前 2 公里处发生撞车事故——我们该怎么办？ 领骑列车的所有成员都向前移动一个位置，因此原本应该在最后阶段支持冲刺手的车手现在将成为冲刺手。 我们已经建立了一个具有非常短的平均修复时间的自愈系统。
回到 DevOps：一些糟糕的代码已经通过了你的流水线。 你不能仅仅依赖编写代码的人来解决这个问题。 在理想的世界中，我们使用版本控制来帮助团队中的其他人弄清楚如何修复该问题。 我们可以设计系统，通过自动将失败的更改恢复到较早的状态来实现自我修复。
团队中的每个人都明白他们拥有跨职能的角色。 这并不意味着我们没有专长或我们比其他人更喜欢的领域； 这只是意味着我们是一个实干家团队。 这与使用 DevOps 原则有效工作的团队相比较。 无论你一开始的职业生涯是应用程序开发人员还是系统管理员，你都必须完成工作并为组织的更大利益解决问题。
从本质上讲，你作为 DevOps 从业者的整个角色是通过实施流程和工具来帮助提高生产力并减少错误，从而使其他人的生活更轻松。 在自行车队中，每个人都为整个组织的成功而努力，而不仅仅是为了自己。
DevOps 角色可以与自行车运动中的副将相比较。 在自行车运动中，我们紧随前方车手的车轮后方骑行，我们的前轮和他们的后轮之间可能只有一英寸的距离。 我们这样做是因为后方的人大约能节省 30% 的功率。 副将负责让其他人的工作更轻松。 他们不为个人荣耀而努力，而是为团队的更大利益而牺牲自己。
你组织中的 DevOps 架构师或工程师（免责声明：是的，我相信每个人都有责任实践 DevOps 方法，但通常有一个人对 DevOps 以及如何在整个组织中实施 DevOps 拥有最强的知识）不会花时间思考如何炫耀他们编写的令人惊叹的代码或他们构建的系统。 他们正在思考如何让你的日常流程更轻松，并为团队的利益解决问题。
图片来源：Victor Chan, oneimagingphotography.smugmug.com
我们一起训练，快速失败，持续学习，并取得成功。 用丰田汽车公司创始人丰田喜一郎的话来说：“他们没有从生产原始产品所经历的失败中获得的专业知识……窃贼或许可以遵循设计图纸并生产出织布机，但我们每天都在修改和改进。” 因此，你可以窃取他们的计划，但如果不了解他们的失败和持续的开发，你将无法创造出相同的产品。
相比之下，另一支自行车队可以找到我们训练方式的蓝图并尝试效仿，但他们不了解我们作为一个整体是如何运作的。 他们不了解我们的失败以及我们为发展到现在的水平所学到的东西。 我们实践持续改进和持续学习。 我们不断地努力改善我们以前的表现。 如果我们赢得自行车比赛，我们不会回家，高枕无忧，然后说：“我们是最棒的团队，没有人能击败我们。” 相反，我们分析我们的表现，而且很可能有很多我们可以做得更好的事情，即使我们赢得了比赛。 我们为什么要这样做？ 因为如果我们有一天犯了小错误，其他团队可能会胜过我们。
在科技世界中，我们可能已经实现了迄今为止最快、最安全的部署，几乎没有失败，但我们是否会沾沾自喜并停止改进？ 这与我们在 DevOps 环境中应该做的事情背道而驰。 我们应该不断地寻找改进我们以前工作的方法。 在组织层面，企业本身需要保持竞争力并确保满足客户需求； 技术使企业能够与这些目标保持一致。
对于自行车队来说，这些流程运行良好，并且他们不断改进。 ChatOps 的实施帮助我们发展了我们的文化并促进了协作。 当我加入车队时，我们通过电子邮件进行沟通。 这种方式缓慢、笨拙，而且通常不是 16 人团队进行沟通的最佳方式。 我们的收件箱总是满的，我们有时会错过消息。
Slack 登场。 起初，有些人抵制变革的想法：“我们为什么不直接使用电子邮件？ 它更容易。” 使用电子邮件并不比 Slack 更容易； 他们只是不想改变和学习使用新工具，即使只需要几个小时。
这是我在尝试在企业组织中实施 DevOps 工具时经常看到的一个问题。 即使使用 Docker 或 Kubernetes 会带来巨大的好处，人们通常也不想改变他们所知道的东西。 作为 DevOps 顾问，我们 практикуем 同理心，并在短时间内展示改进来解释好处，从而指导文化和程序转型。
自行车队最终使用了 Slack，在我意识到之前，整个团队文化都变得更好了。 我们使用各种频道来保持井井有条，例如“比赛”、“团队骑行”、“ICE”（紧急情况）、“教练”、“随机”等等。 文化得到了改善，因为我们能够联络、娱乐和相互开玩笑，而不必担心扰乱其他频道中的重要对话。 我们的教练在圣莫尼卡，而我们在纽约，但我们感觉他就在我们每次训练骑行的身边。
我已经看到 Slack、Trello 等协作工具被用于改善许多远程分散团队中的协作。 但是，改善文化有什么重要意义——人们不应该只专注于做自己的工作吗？
当然，他们应该。 我并不是说这些工具应该是一种干扰。 但将团队聚集在一起意味着他们更有可能在需要时进行协作。 这将帮助全球团队更有效地沟通和协作，并且还将提高员工满意度，因为人们会感到更大的归属感。
总而言之，敏捷和DevOps方法论可以应用于技术领域之外。这些原则和实践可以在整个组织内实施。 它们可以帮助管理变革和转型，同时通过自动化和采用云计算的现代技术来提高生产力。不要只关注DevOps工具。
【查看我们的相关文章，如何在IT之外应用DevOps文化】
评论已关闭。