在对讲机公司，我们有一些价值观支撑着我们的工程文化——快速发展但长期优化；做得少但做得更好；以及掌控我们的责任范围和我们建造的东西。这些价值观使我们作为工程师更加自主，因为它们为我们提供了一个更好的决策结构。当你习惯于一直和他们一起工作时，他们可能会淡入幕后，但在与团队隔离工作时，他们会变得特别有用。几个月前，我去芝加哥是因为个人原因，所以要离开我的团队工作两周。一天的大部分时间里我所在的时区都没有其他的工程师，所以选择一个自始至终都可以拥有的独立项目是必要的。我的工程团队，生产系统，负责内部通信基础设施的可用性、可扩展性、安全性和成本。从我们的积压工作中可以看出一个突出的问题：通过最大限度地使用Spot实例，可以将amazonweb服务（AWS）成本降低50%。这种备用AWS计算能力的成本根据可用性和需求每小时变化一次。我们需要使Spot实例在对讲机中的使用更安全、更容易。我们使用自动扩展组（ASG）管理EC2主机。amazonweb服务使得在asg中启动Spot实例非常容易；您只需设置愿意支付的最高现货价格。有时，AWS现货市场会导致现货价格非常高，集群没有容量，因此使用Spot实例进行"近实时"集群非常危险。但是，如果在这些市场波动期间，我们可以用随需应变的实例替换Spot实例，您只需为实际使用的EC2实例付费，我们就可以扩展Spot实例的使用，从而显著降低AWS的运营成本。今年年初，该团队尝试部署一个名为Autospotting的开源项目。从描述来看，它似乎解决了我们所有的问题，但是在部署之后，我们认为它不适合我们，因为它似乎是为比我们的更简单的架构设计的。我们需要使Spot实例在对讲机中的使用更安全、更简单，我们认为我们有两个选择：fork Autospotting使其在我们的环境中工作，并在以后将更改向上游传输；或者只使用我们需要的位来构建我们自己的autosposting实现。这些方案提出了一个有趣的技术挑战，相对较小，影响很大，正是适合我此行的项目类型。减少摩擦为了优化我离开的两周时间，我需要我的团队事先就系统设计达成一致意见，以便在另一个时区减少通信摩擦。自主性不仅仅意味着"自己工作"。自主性不仅仅意味着"自己工作"。这意味着你可以选择一个项目，拥有自己的设计并设定自己的成功标准。在对讲机公司，我们不需要签核——我们需要自己做"充分的尽职调查"，并根据需要引入其他利益相关者和高级工程师。这意味着设计的早期调整对于工程师的自主性至关重要。因此，我评估了每个选项，并与团队成员分享了我的想法，以获得反馈。以下是总结：选项1：叉子自动封装。Autospotting是一个在Lambda中运行的Go二进制文件，它有一些局限性Go在对讲机中的使用越来越普遍，但还不是一种标准技术。我的团队中有一半人从来没有和它合作过，包括我自己。修补它需要我学习Go，代码库和补丁，以满足我们的需要；所有这些都是在离开团队的2周内完成的，比他们提前6个小时。选择2：建立我们自己的解决方案。通过全权委托，我可以从第一天开始用Ruby编写代码，只构建我需要的特性，并在第二周结束前将服务V1投入生产。我更喜欢选择2；这项服务将成为我们基础设施的核心组成部分。它必须是可靠的，团队中的每个人都能理解。在没有得到团队更多支持的情况下，我对分叉和修补autospoting感到不舒服。在这种情况下，代价太高，无法继续尝试实现自动封装，我可以通过构建自己的实现更快地产生更大的影响。团队同意我的计划。我承诺在一周内提供一个内部通讯系统的自动封装的纸杯蛋糕，然后就动身去了风城。烤纸杯蛋糕我想从小事做起，建立一些能证实我的方法的东西，并向我自己和我的团队证明，建立我们自己的解决方案是可行的。所以在周一早上，我开始构建一个简单的同步Ruby服务的原型，它将替换我的测试ASG中的实例并优化成本。我叫它ASG优化器。一开始，我本可以开始设计一个完美的服务，它将覆盖所有的边缘案例，完美的可扩展性和极高的效率；但是考虑到我只有两周的时间来完成这个项目，我不想把时间花在我还没有解决的问题上；我想证明这是个合理的选择。在周末，我有一个进程在同步监视我的ASG，获取一个随需应变的实例，复制它，并在通过EC2检查后交换它们。我最初的承诺是这样的：

做蛋糕为了使ASG优化器准备好生产，下一步是用概念证明来解决最大的痛点：可伸缩性。通过最初的提交，我每分钟只能替换数千台主机中的一台。这对对讲机这样的基础设施来说是行不通的。因此，我将ASG优化器移到异步模型中，并使用SQS将单个进程拆分为三个进程：流程1监视所有带有标记"AsgOptimiser"的自动缩放组，并将任何替换候选组添加到"Spot Instance Creator"SQS队列中。进程2轮询了"Spot Instance Creator"队列，创建了一个Spot实例，然后将[new Spot Instance ID，old On Demand Instance ID]添加到"Instance Swapper"SQS队列中。进程3轮询了"instanceswapper"SQS队列，等待Spot实例通过EC2检查，交换实例，并终止旧的按需实例。

第二周结束时，我将新的异步服务部署到生产环境中，优化了一个自动伸缩组，为我的团队准备了一个推出计划，然后回到了都柏林。然后在接下来的星期一早上，我将它用于我们所有的近乎实时的集群，并了解到它还需要做一些工作，比如减少对AWS的API调用的数量以及引入孤立实例清理。ASG optimizer现在为大约140个自动缩放组启用，每天替换大约650个实例。随着时间的推移，这将使我们的EC2账单减半。

锦上添花即使两周的工程工作也会对运营成本产生重大影响。但是，即使ASG优化器现在已经投入生产，而且项目在技术上已经完成，我仍然在寻找改进它的方法。ASG优化器是为了解决对讲机的问题而构建的。我们最近注意到，ASG优化器并不能很好地使用我们以前的成本策略，即使用保留实例来节省我们知道需要的实例的资金。我们现在使用了太多的spot实例，而没有完全使用我们的保留实例？为了解决这个问题，我们一直在考虑让服务保留实例知道。我很乐意开始使用Spot实例，不仅是为批处理工人，而且也为面向用户的web舰队使用Spot实例。ASG优化器工作流也可以用于更新我们的自定义Amazon机器映像（AMI），它定义了EC2实例的操作系统。我们的持续集成和持续部署系统也完成了我们的AMI部署。AMI的推出可能会阻止部署，并在重新启动一切时给我们的数据存储带来压力。将工作卸载到ASG优化器将有助于我们安全地替换旧的AMI实例，并消除重复的逻辑和复杂性。ASG optimizer的构建初衷是为了解决对讲机的问题，可能并不适合所有人，但如果社区有兴趣，我们愿意将其开源。当你自主工作时，与你的团队保持一致是至关重要的。最重要的是，记住，当你作为团队的一员工作时，坚持与你相同的方法和原则将带来最好的结果。如果这听起来像是你想提升你的工程生涯的地方，我们正在招聘系统工程师。