丰田如何指导我们基础设施的发展（并使我赞赏吉拉）
反思我公司的微服务，DevOps和完美价值流之旅
在制造业中，价值流图（VSM）是用于衡量绩效的流行工具。 VSM由Toyota闻名，本质上是一个流程图，描述了创造价值的必要步骤。
例如，为椅子工厂考虑这个简单的VSM。
此示例说明了工厂在收到订单后需要制作椅子的四个步骤：焊接，喷漆，组装和检查。
这里有两点值得指出。
- 这些步骤必须按顺序进行。 在此示例中，必须在焊接后为每把椅子进行绘画。
- 这些步骤可以针对不同的工作项目并行完成。 在此示例中，这意味着涂漆和焊接可以同时发生，但适用于2个不同的椅子。
- VSM的总时间是所有步骤的总和。 在此示例中，每把椅子从开始到结束需要7天。
- 输出速率是工作项可以流过VSM的速度。 在此示例中，如果每个步骤始终需要椅子，则我们的工厂每3天可以生产1把椅子。
最后一点特别值得注意，因为它说明了总时间和输出速率之间的差异。 在决定如何改进流程时，输出率说明了为什么我们应该专注于最长的步骤（或最大的瓶颈）。 在此示例中，我们的工作流仅受检查约束。
此示例与椅子有关，但是Value Steam Maps也可以描述软件交付。 考虑下面的另一个VSM； 这类似于制作椅子。
在此软件示例中，“部署”是最长的步骤，这意味着尽管其他步骤有多快，每个功能请求的输出速率至少为3天。 换句话说，此VSM告诉我们Deploy实际上是我们的唯一约束。
以上两个示例都是过分简化的“价值流图”，但它们说明了为什么只有最大的瓶颈才重要。 当我回顾我公司的架构在过去几年中如何发展时，我意识到正是这些瓶颈引导了我们最大的变革。
瓶颈如何引导我们的基础架构的故事
最初，我公司的旅程始于几个开发人员，而没有其他人。 由于团队很小，因此协调很容易，并且由于不存在任何遗留系统，因此无法提供支持。 这提供了确定业务和产品的敏捷性。 我们的价值流很清晰。
然后我们的公司成长了。 用户增加，产品不断发展，这意味着需要新的系统。 但是管理这些系统需要我们花时间去开发。 这成为我们的第一个瓶颈。 因此，我们引入了Capistrano和Puppet之类的工具来管理我们的系统，因此解决了我们的第一个大瓶颈。
但是我们的公司继续发展。 出现了更多的开发人员，以及更多的部署，修补程序和配置。 我们的自动化有所帮助，但是许多任务仍然需要我们唯一的Sysadmin进行人工协助，他很快就不知所措。 这成为了我们的第二大瓶颈，结果，雇用了更多的Sysadmin管理员，并组建了一个基础架构（或SRE ）团队。
此时，我们主要使用Ruby和MySQL，而我们的SRE团队允许我们进行扩展。 但是很快我们将需要JavaScript和Scala，以及Kafka集群和Cassandra数据库。 这成为了我们的下一个瓶颈，因为我们引入的每项新技术都产生了独特的要求，这些要求阻碍了SRE团队采用系统特定的程序。 因此，我们将系统迁移到Docker和容器编排（或微服务）平台上 ，为Sysadmins提供了一个通用接口，以随着技术选择的扩展来支持各种系统。
容器使我们能够支持多种技术，但它也鼓励开发人员更多地参与其系统的操作。 这意味着越来越多的团队要求Sysadmin管理员更改其容器。 团队的建设速度越来越快，并且DevOps越来越多，但是对SRE团队的依赖成为了新的瓶颈。 认识到我们组织中的这种趋势，导致创建了一个自助服务门户，供开发人员在没有Sysadmin的情况下（甚至在生产中）应用特定更改。 最初，此门户允许用户设置其容器的CPU和内存限制，这是当时最受欢迎的请求，但是随着其他常见请求（或瓶颈）的出现，功能也被添加。
该门户网站使团队可以自由地工作，从而帮助推动了整个公司的DevOps运作，但同时也使我们面临着成本管理和访问控制方面的新挑战，不用说，这些挑战不会终结。 解决这些挑战后，我们很可能会再次发现更多瓶颈。 瓶颈永远不会停止，但请放心，这不是一件坏事。
我们基础设施的故事并不新鲜，但是我发现启发人的是认识到我们旅程的无穷无尽。 完美的基础架构不存在（任何软件产品都可以如此），但这并不意味着我们应该停止尝试改进。 到达终点并不像前进一样重要。
持续的瓶颈导致持续改进
解决瓶颈是一件好事。 瓶颈代表了可以改进我们的工作方式。 他们通过迫使我们不断地问自己如何创造价值以及该价值是什么来指导我们的努力。
在我最喜欢的 《社交网络》 （ The Social Network） 场景中 ，爱德华多（Eduardo）问马克，什么时候可以完成创建Facebook的工作，这样他就可以开始从中获利。 马克恰当地回答说，Facebook永远不会做，就像时尚永远不会做一样。
这个场景引起了我的共鸣，因为我认为它不仅适用于Facebook，而且适用于所有形式的手工艺品，无论是软件，艺术品，音乐还是其他东西。 总是可以汲取经验教训，可以一直取得增长，就软件交付而言，Value Streams可以发现导致最有意义的改进的瓶颈。
曾经有人告诉我，构建软件就像构建铁路一样。 该过程从开创性开始，然后是构建，最后是优化。 尽管这种比较有时是有用的，但仍缺乏“优化”的最终性。 相反，我更喜欢将软件开发与《星际迷航》进行比较，它的持续探索任务就像探索宇宙一样，永远也不会完成（和改进）构建。 我们只需要决定去哪个方向。
椅子和编写软件之间的真正区别
制造和软件共享持续改进的旅程，但这就是价值流图的相似之处。 制造业与物质世界打交道。 在工厂车间，您可以看到工作项以及工作流本身。 哪一步是瓶颈和容易出错甚至可能是显而易见的。 使用软件并不是那么容易。
有了软件，工作就可以实现电子化，而工厂车间则是一个充满计算机的房间。 很难看到有人要执行的任务或工作流程是什么。 软件是无形的，这是软件与制造真正的区别所在，以及为什么像Jira这样的工具对于此类工作如此重要。
Jira是一个用于软件团队的任务管理系统，用于描述和跟踪工作项目，其进度，所有权，所花费的时间以及其他对理解效率低下和构建有意义的价值流图至关重要的信息。 人们通常认为这些任务管理系统仅用于计划未来的工作，但是其价值的很大一部分来自于他们记录过去的方式，因此我们可以使其合理化，以便将来做出更好的决策。
为了理解开发人员的生产力及其驱动因素，已经做了很多工作。 在DevOps时代，这导致人们认识到部署频率，变更提前期和其他此类开发人员指标 。 但是，以我的经验，没有什么能比简单地记录日记和时间更普遍有效了。 我坚信个人从日记和反思中获得的收益（例如以下收益）也适用于组织。
对于任何软件公司而言，最重要的一件事就是了解其如何创造价值。 许多公司会迷失在技术或组织结构之间进行选择，但这与本质无关。 唯一重要的是如何创造价值以及阻碍实现的障碍。 通过引用这些经验（使用Jira或其他工具）并进行反思，我们不仅能够认识到我们遇到的障碍，而且还能揭示前进的道路。