通过三段式工作的团队需要一个不偏不倚的方式来判断他们的进展。 也就是说，你怎么知道“我们在哪一阶段？

像任何旅程都有里程碑。 我称之为"Look-for's"。 正如在这些"look-for's"的东西，可以帮助你确定一个团体如何进行他们的旅程。

由于有三个阶段，人们期望有4个里程碑，“起点”加上里程碑标记着每个阶段的完成。 我在第一阶段添加了一个里程碑。 这样在第一阶段的中间就有一个明显的序列点即团队从总混乱到管理混乱。

里程碑

 

Look-For's

里程碑1 (No Way) Look-For's

在这个阶段你还没有开始。 你可能做好也可能做不好，你不知道该如何做，因为没有记录，自动化或测量。

•结果不一致。

•不同的人以不同的方式执行进程。

•流程未记录。

•团队管理者不能列举团队所做的所有流程（即使在高级别）。

•IT部门负责“一切与电源插头相关的事”，因此，无法做任何事情。

•请求丢失或无限期停止

•无法预测通用任务完成需要多长时间。

•很少或没有测量或度量。

•无仪表板。

•你认为客户很高兴，但并不是。

•提出缺陷却仅仅是没有注意操作问题。

•制定优化（或奖励）是很常见的，这有利于个人或小团体损害较大的组织或系统。

•部门目标强调部门绩效不利于组织绩效。

里程碑2 (Way 1a) Look-For's

端到端过程由多个人记录和重复。 有很少的特定步骤（如果存在，则它们将被识别）。 该系统产生相对一致的结果。

•端到端过程包含列举的每个步骤，具有依赖关系。

•端到端流程将每个步骤的流程记录下来。

•不同的人以相同的方式完成任务。

•然而在流程中会有一些重复的努力。

•然而多个任务所需的一些信息可能需要它的每个步骤重新创建。

里程碑3 (Way 1b) Look-For's

第一阶段 已经实现。 流程是一个方向：从左到右（即工作不需要回去重新完成或修复）。 缺陷不会沿着线传递。 过程变化不再是过程意外。 我们可能没有实现我们的目标，但至少目标是明确的。 例如，我们现在知道我们希望在48小时内完成所有新的服务请求，但是我们可能不需要去考虑估算这个完成时间来看我们是否达到了这个目标。

•每个步骤在交付到下一步之前都有质量检查清单。

•有一个过程，通过这个过程，所有人都可以了解对其他人的流程的变化（例如：Ops参加Dev开发人员; Dev参加Ops会议）。

•多个步骤所需的信息被创建一次。

•没有（或最少的）重复劳动。

•能够重复流通流量。

•成就达成：第一阶段

里程碑4(Way 2) Look-For's

第二阶段已经实现。反馈流向上游，从而可以改进过程并减少意外。问题被放大，而不是隐藏起来。对于每个步骤，我们测量等待时间，任务持续时间，缺陷数量和返工工作。

•所有步骤都有反馈机制。

•由最能解决问题的人分享痛苦。

•存在显示每个步骤完成时间的仪表板;每个步骤的滞后时间。

•存在显示当前瓶颈，积压，空闲步骤的仪表板。

•仪表板显示缺陷和返工计数。

•定期（每周）审查缺陷和返工。

•事后发布以供所有人查看，X小时内初稿，X天内最终。

•定期审查受影响团队的警报。跨职能团队定期审查警报。

•过程更改请求需要数据来衡量已修复的问题。

•仪表板以业务术语（即不仅仅是技术术语）报告数据。

•每个“故障转移过程”都有一个“最后使用日期”仪表板。

•在需求之前预测能力需求。

•第二阶段，成就达成

里程碑5 (Way 3) Look-For's

第三阶段已经实现。团队中要有一种实验和学习的文化，要花费更多的时间去创新。操作应由科学驱动，而不是传说或是猜测。

•进行过程更改后，在数据比较之前/之后确定成功。

•如果在数据显示没有改进之前/之后，过程更改将恢复。

•已经采取行动的过程变化来自各种来源。

•至少有一个过程变化来自每个步骤（在最近的历史中）。

•周期时间有月份改善。

•存在一个机制使得在近期历史中未使用的任何故障转移过程被人为激活。

•定期（季度或每月）进行压力测试和故障转移测试。

•定期（至少每年）进行一次“游戏日”练习（密集，系统级测试）。

•团队里有统计人员。

•通过提取的实际数据建模“假设”情景来做出决策

•第三阶段，成就达成

常问问题

问：必须这样做吗？

答：DevOps的存在是因为有这个需求或者有问题要解决。 对于DevOps来说没有特定的“规则”，只能是在部署上提供一些指导，最佳做法和技术。对比这个来运行系统鼓励人们做事情，因为有些书说你必须这样做。当你盲目的做事情的时候，这种系统往往会导致管理混乱。

DevOps是一种文化，而不是必须盲目遵守的“规则”。因此，这些“Look for's”不是规则。一个团队不应该试图“检查每个盒子”。如果管理层因为不能找到列表上的一些数据而给你一个糟糕的绩效审查，那他们做错了。这些不是唯一的看起来，只有那些我发现为我工作的。

也就是说，你不必吃蔬菜，但他们对你有好处。我认为这样的自我评估对你有好处。 （像...为什么我会写这一切？）

问：DevOps的第三阶段是什么？

A：Gene Kim的“三种方式”是DevOps的基本原则。 最快的方式来了解他们是Tim Hunter的描述。

在所有三个原则下运作的团队具有弹性和可变性。 他们有信心在不会导致中断或其他问题的情况下做出改变。 这种信心驱使着使实验。 创新来自于尝试新事物。 因此，团队的大部分能量通过实验可以并且用于创新。

相反，一个过于保守的团队。 没有人有时间做出重大改进，因为每个人都非常专注于保持现状，这是一种混乱和绝望的文化。

问：你为什么把第一条分成两部分？

A：第一种方式是这样一个漫长的旅程本身我认为这是有道理的。 上半部分是“让系统工作”，下半部分是“定义期望”。 在上半部分，我们得到了正确的流程（记录步骤以便每个人都以同样的方式做）。 另一半我们完成了第一条路的其余部分（业务目标已经定义）。 我们可能不会达到这些业务目标，但至少该过程是坚定的，我们可以定义它们。

问：这些“寻找”都错了。 我有更好的。

A：我相信你，这些没有 “规则”， 只是为我所用，我很乐意在这里加上你所提出的 “look-for's”，可以随时给我发电子邮件或发表评论

问：什么是“从左到右”的业务？

A：大多数进程都有一系列步骤，列表将步骤作为在看板上的列。 作为“工作项”完成一个步骤，它将移动到下一列。 也就是说，它向右移动。 在混乱的过程中，工作项目向右移动，然后向左移动一点工作，然后向右移动。。。一团糟。 简化的过程仅将工作项从左向右移动。

一旦定义一个过程，使得正常流量是从左到右的，但是在工作项目向左移动的情况下可能仍然存在异常。例如，假设的“步骤3”做错了，因此“步骤4”将其发送回“步骤3”以被修复。 这就是“返工”。 减少返工的数量是一个重要的目标，这可以最有效地使用某人的时间。 返工请求应该被计数，并应该消除最常见的返工原因。

Q：人们会将5个里程碑与3种方式混淆吗？

A：这值得关注。最初我把它们标记为A-E而不是1-5，看起来很像成绩。得到A听起来像一件好事，因为在学校里，“A”代表一个好成绩。

我也考虑了用0, 1/2, 1, 2, 3和0，1a，1b，2，3来进行编号。

所有这些方案的问题是，一个团队从来没有“准确地”是一个里程碑。一般是“接近”一个或“刚刚过去”另一个。 你的团队可能有一个深入第三方的过程，另一个过程在第一个里程碑。你能说平均这两个，然后说是在“里程碑3”吗？ 网格更合适吗？ 下面有更多的想法。

我也曾考虑过用CMM里面的名称来给里程碑命名。CMM是漂亮的“老学校”，但名称合适。 我还添加了颜色，因为生活应该是丰富多彩的。

再次，欢迎大家建议，可以随时给我发电子邮件或发表评论。

如何使用这个

Look-For的是一个工具。使用工具有很多方式。

首先，您可以用它们来评估单个项目。您或团队可以定期审核列表并进行评估。这有助于团队明确地确定他们在哪里，因为“look for's”是来自外部的。

其次，您可以使用此模型来评估服务的各种功能。很多DevOps文化会涉及到从“我管理一台机器”到“我提供服务”的想法。面向服务的思维是，IT未来的方式——IMHO。

也就是说，任何服务都有一定的“领域”的能力。一个团队可以对每个人进行评估。每个公司的竞争可能不同，但我认为有些还是相通的：

定期请求。

紧急请求（中断和/或紧急请求）。

监控和度量。

容量规划（我们如何知道未来需要什么资源）。

变更管理（如何计划，完成和测试变更）。

新产品介绍/退役（你如何接受[例如]新的硬件变化，以及贬值的过时的变化）。

您的团队可能有不同的域名。例如，一个“全球化”的小组可能会不断扩展到新的数据中心。您可以将“数据中心调高/调低”添加到列表中。

这将浪费时间和精力使每个域或每个服务成为里程碑5。而对于某些域来说里程碑3就足够了。例如，如果服务不增长，我们可以看到“容量规划”在里程碑3是“刚刚好”。你不能欺骗团队说对所有域有“里程碑3就足够了”。

最后，您可以使用此模型以更大的规模执行DevOps。

大规模的情况下，你可能有10-20个项目在某些时间同时进行。作为Director或CIO，在迁移到DevOps时，你如何该怎么做，每个团队该如何做？如何保持“大图片”没有微管理？一种方法是让每个项目负责人及时了解团队已经取得的“里程碑”。作为Director或CIO，你可以保存一个随时间显示评估级别的电子表格。例如，列出左侧的每个项目（A列），然后为每个月添加一列。您可以对条目进行颜色编码以获得“热图”效果，以查看项目的进度。

聪明的项目负责人会对小组讨论和决策进行评估。通过让团队做自我评估，帮助团队看到需要改进的地方。自我评估比经理给你的评估更有动机。

作为Director或CIO，你的工作是建立公司范围内的“look for's”，以便每个人都使用相同的标准。

最后，如果电子表格是公开可见的，它使团队能够将自己与其他团队进行比较。这提供了进一步的动力。它还有助于保持团队的诚实。为了减少官僚主义，不能评估太频繁，季度制可能更好一点。

如何使用这个

Look-For的是一个工具。有很多方法可以使用工具。

首先，您可以使用它们来评估单个项目。您或团队可以定期审核列表并进行评估。这有助于团队诚实地确定他们在哪里，因为“寻找”来自外部来源。

其次，您可以使用此模型来评估服务的各种功能。很多DevOps文化谈到从“我管理一台机器”到“我提供服务”的想法。面向服务的思维是，IMHO，IT未来的方式。

也就是说，任何服务都有一定的“领域”的能力。一个团队可以对每个人进行评估。每个公司的竞争可能不同，但这里是我认为最常见的：

•定期请求。

•紧急请求（中断和/或紧急请求）。

•监控和度量。

•容量规划（我们如何知道未来需要什么资源）。

•变更管理（如何计划，完成和测试变更）。

•新产品介绍/退役（你的同化[例如]新的硬件变化，以及贬值过时的变化）。

您的小组可能有不同的网域集。例如，一个“走出去”的小组可能会不断扩展到新的数据中心。您可以将“数据中心调高/调低”添加到列表中。

这将浪费时间和精力使每个域或每个服务成为里程碑5.“3对于某些域是足够的”。例如，如果服务不增长，我可以看到“容量规划”在里程碑3是“足够好”。你不能让一个团队“欺骗”通过声明“3是足够”的所有域。

最后，您可以使用此模型以更大的规模执行DevOps。

在大规模，你可能有10-20个项目在任何时间。作为董事或首席信息官，你如何掌握每个团队如何在迁移到DevOps？如何保持“大图片”没有微管理？一种方法是让每个项目负责人及时了解团队已经取得的“里程碑”。作为Director或CIO，您可以保存一个随时间显示评估级别的电子表格。例如，列出左侧的每个项目（A列），然后为每个月添加一列。您可以对条目进行颜色编码以获得“热图”效果，以查看项目的进度。

聪明的项目负责人将使评估成为一个小组讨论和决策。通过让团队做自我评估，它帮助团队看到需要改进的地方。自我评估比一个经理告诉他们为你选择的评估更有动机。

你作为导演或CTO的工作是建立公司范围内的“寻找”，使每个人都拥有同样的批判。

最后，如果电子表格是公开可见的，它使团队能够将自己与其他团队进行比较。这提供了进一步的动机。它还有助于保持团队的诚实。为了减少官僚主义，你不应该让评估太频繁。季度可能很好。

最后的一些想法

有时候我们不停的工作，一年后，我们没有办法认识到取得了多少进展。 一旦我们达到美好的日子，我们往往就忘记了那些不幸的日子。 通过自我评估，我们不仅能更好地了解需要去哪里，而且能够知道我们已经到了多远。 通过在电子表格中记录这些评估，它成为我们进步的见证; 令人骄傲的东西。

同样，我想强调的是，这些是“look-for's”，不是硬而快的规则。 你不必靠遵守所有的要求来声称达到个特定的里程碑。不是所有的“look-for's”都适用于每个团队，你可以添加自己想要的。

正如苏格拉底所说，“未经审视的生活是没有价值的”。 我不认为他做了很多DevOps，但他肯定有这个权利。 通过定期评估帮助我们了解团队在哪里，我们要去哪里，帮助我们回答这个问题“我们还在吗？”

 

【英文原文：http://everythingsysadmin.com/2013/09/devops-lookfors.html】

{测试窝原创译文，译者：周婷婷}

译者简介：周婷婷，专注于云计算、自动化、网络运维领域的工作者。