引导阶段
在过去的6年里，我有着独一无二的机会观察我们公司是如何由几个只想着出 租教科书的应届毕业生发展成一个大而成熟的公司。当我回头看时，我会将我们 的成长分成两个不同阶段：A轮融资之前和A轮融资之后，与你听到或读到的大部 分创业公司不同，我们经历了相当长一段时间的A轮融资（大概有3年）。
在这一发展阶段，我们并没有花费大量的资源或人力在DevOps上，相反我们主 要关注产品的构建。在刚开始几年的大部分时间里，我把自己定位为一软件工程 师，每月只需几天时间花费在系统管理上。
我们经常开玩笑说，我是那个抽到下签，被“困于”服务器管理的 那个人。但是，实际上，我自己特别享受。尽管如此，我也从来没想过我对软件 开发的热情居然会用在服务器管理上。
尽量简单（在你能控制的范围）
我们初期之所以能不在DevOps上花费力气是有几个原因的。首先，很大程度上 是因为我们是小公司，变化也比较少。我们选择了一个简单的架构，应用程序数 量也比较少。所以尽管我们的产品不断发展，但是需要对底层的基础架构进行修 改的地方却比较少。
过度投资
第二，早期我们在服务器硬件上投资过度了。我们可能只需要两台服务器就可 以运行我们整个网站，而我们却买了10台。但这允许我们之后花很少的时间去担 心那些性能或基础架构发展等问题，而我们也是在几年之后才耗尽初期购买的服 务器的性能。当然，配置这些服务器是有前期成本的，但是一旦设置好了，就不 需要大的改动。
选择好的工具
最后，我们采用Ruby on Rails作为应用程序框架，及其关联的工具，比如： Git、Capistrano和Teamcity，允许我们在早期就采用那些良好的发布和部署实践 。与此同时，我们也构建于那些行之有效且稳定的开源解决方案之上，比如： nginx、MySQL和memcached。
也正因为对这些工具和框架的采用，从而让我们避免了采用不必要的复杂且专 有的解决方案。很多时候我觉得这些方案会随着公司的成长，降低其开发速度。
成长
随着我们公司进入第二个成长阶段，我们的工程师和产品团队也稳步增长。只 有两个开发人员的日子已经一去不复返了，一眨眼间，我们就有10个，甚至20个 人为现有的以及新产品工作。可想而知，我们需要引进的变化数量也会稳步增加 。我们的硬件上需要承载的应用绝对数量也直线上升，先是以前的两倍，然后三 倍。同时开发人员也想使用新的应用框架、编程语言、数据库、排队系统及缓存 服务器等。
随着这些复杂性的增加，错误和停机的成本也增加了。很快我们发现旧的手动 配置基础架构已不再适用，而我们基础架构层对成熟性和灵活性的缺乏也将给我 们带来以下问题：减缓新产品和功能的发布，危害我们的稳定性。认识到这一点 ，我停止了在产品上的工作，并将重点全部放在研究开发自动化、监控和发布流 程上。
引进Chef
幸运的是，我们认识到我们需要实行DevOps实践。而当时，我们遇到了 OpsCode Chef，以及它所倡导的“基础架构即代码”原则。最初，我 们花费了几个月时间为现有基础框架的每一部分编写自动化脚本。一旦完成，我 们就可以利用这些自动化脚本重构所有服务器，这将大大减轻我们肩上的负担。 现在我们所有服务器都已设置一致，而我们最终也有一个地方能让团队所有人都 可以看到每块基础架构到底是如何建立和设置的。同样重要的是，它允许我们快 速地将额外资源添加进来。
DevOps团队的成立
DevOps开始在公司内担负起独特的责任，为我们的产品线提供关键支持，并保 证我们的基础架构可以持续拓展。除了这些重点之外，我们也在不断开发工具和 产品，用于管理这些需要持续支持和改进的基础架构。尤其在前期，通常来说如 果往基础架构中引进新的应用，就要求对底层自动化脚本进行修改。由于越来越 多人开始依赖我们的工作，内部用户（开发人员和运维人员）也随之提出了更多 与DevOps相关的需求。
由于我们的开发团队已经分为不同的产品团队，且每个团队都关注不同的业务 ，我们决定设定一个单独的DevOps团队。这样我们就有一个专门的团队全职解决 基础架构问题。另外，应用平台的可用性和稳定性对我们的业务来说也是及其重 要的，宕机或别的问题对我们的服务都会有很大的影响。我们需要随时保证有专 门的、训练有素的工程师来协助和调查问题，尤其当问题的归属可能跨越多个团 队或无法当时就明了时。
自动化果实
按需配置
在采用Chef和自动化我们产品的基础架构之后，我们立马着手做的事情就是改 善我们的测试和staging系统，给它们配上同等程度的自动化。我们经常听到的抱 怨之一就是开发人员无法简单快速地给业务人员展示他们当前所做的工作。为此 ，我们开发了一个100%自助服务的门户，这样公司里的任何人都可以启动一个预 配置服务器在EC2上运行完整的程序。
