技术生命周期
This blog post discusses the strategies that Slack uses to manage the lifecycle (development, support, and eventual retirement) of infrastructure projects, through the lens of the migration through three successive internal “platform” offerings.
这篇博文讨论了Slack用来管理基础设施项目的生命周期（开发、支持和最终退役）的策略，通过三个连续的内部 "平台 "产品的迁移镜头。
Our challenges
我们的挑战
Circa 2020, our Cloud Engineering team (now evolved into multiple teams responsible for narrower aspects) was responsible for managing our Infrastructure-as-a-Service providers, compute environments like Chef and Kubernetes, and a large variety of related systems.
大约在2020年，我们的云计算工程团队（现在演变成多个团队，负责较窄的方面）负责管理我们的基础设施即服务提供者，计算环境，如Chef和Kubernetes，以及大量的相关系统。
This team had a broad remit, often with multiple systems and technologies serving overlapping purposes, and this broad remit caused several problems for us.
这个团队有广泛的职权范围，往往有多个系统和技术服务于重叠的目的，这种广泛的职权范围给我们带来了几个问题。
These overlaps meant we would spend valuable time recreating new features in multiple projects, instead of writing new functionality just once.
这些重叠意味着我们将花费宝贵的时间在多个项目中重新创建新功能，而不是只写一次新功能。
Retiring older technologies to focus on newer ones was challenging, because these older technologies still served important responsibilities, and we did not have a clear process for migration of those responsibilities to newer technologies.
淘汰旧技术以专注于新技术是一项挑战，因为这些旧技术仍然承担着重要的职责，而我们没有一个明确的程序来将这些职责转移到新技术上。
We also could not easily and consistently communicate with our peers about what they could expect if they chose a specific technology: Would we support them? Address bugs they found? Surprise them with a “deprecation” warning a week after they went live?
我们也不能轻易地、持续地与我们的同行沟通，让他们知道如果他们选择了一种特定的技术，他们可以期待什么：我们会支持他们吗？解决他们发现的错误？在他们上线一周后发出 "弃用 "警告，让他们感到惊讶？
Not only did we not have clear answers to these questions, the un-clear answer a peer received would vary based on who on the team they talked to.
我们不仅对这些问题没有明确的答案，而且同行得到的不明确的答案会根据他们与团队中的谁交谈而有所不同。
Our peers didn’t know which technologies they should — or could — use.
我们的同行不知道他们应该--或可以--使用哪些技术。