转载

做服务而不仅仅是开发软件

今天读到一篇博客，标题为 DevOps – Not Good Enough ，作者 MARTY ABBOTT 的观点大致为，DevOps 把开发、QA、运维等环节打通，解决或缓解了传统 IT 所遇到的很多问题，然而这还不够，我们需要认清最根本的两个问题。第一个问题是：传统企业的 IT 基础设施和架构是为了支持各种各样的第三方软件，其目的是节省成本而不是创新；第二个问题是：传统的软件开发和维护是分离的，开发软件更多的关注是把它卖了，而不太关心软件最终如何运行。

然而，今天行业发生了巨大的变化：

现在，客户购买服务而不是软件。要在这个全新的世界获得成功，就需要改变观点，即组成这些服务的原材料不仅包括软件，也包括硬件（基础设施）。如果你的团队没有合理地组合这些原材料，那么最终服务也不会如预期的那么好。如果继续“生产”软件，然后“托管”在基础设施上，那么最好的结果也仅仅是次优的解决方案，最差的结果则可能是一场灾难。

MARTY 又接着说，我们应该：

把团队组织成跨职能的、实用且多样的、自治的团队，各个团队拥有整个产品中独立的一些服务。各个团队和服务应该由集中面向业务的 KPI 驱动。这些团队应该能够独立自主地开发、部署、支持自己的服务，不需要依赖其他团队。

我们都知道，如果一件工作需要跨团队合作，工作效率会急剧下降，各种推责扯皮的事情就会冒出来，管理成本直线上升，需要富有经验的项目经理协调，需要指定共同的目标，需要开很多很多的会…… 在这种背景下，快速地应对市场变化、开发创新的产品就难免变得困难重重。为什么现在很多很小的互联网公司能那么快速地发展起来，我想一个很大的原因就是因为他们够快，够“敏捷”，现在很多基础设施如代码托管、服务托管、应用程序监控都有了比较成熟的市场及服务（至少在国外），它们中有我们耳熟能详的 Github、Amazon EC2、New Relic 等等，在这些基础设施足够灵活、足够稳定的情况下，小型互联网公司能够专注自己产品和服务，技术人才也比较容易“跨职能”，设想在传统的大的 IT 公司内，一名开发人员要了解运维体系几乎是不太可能的事情，但现在如果是用 Amazon EC2，则只要学习一些简单的 API 即可，而且相关工具也更加简单。

市场上成熟的 IAAS/PAAS 帮开发人员简化了很多问题，也使得程序员关注 OPS 的门槛降低了。除此之外，敏捷运动在帮助开发团队跨职能方面也功不可没，尤其是，敏捷强调开发和测试角色的融合，事实上，现在优秀的开发人员都具备比较强的测试意识和测试技能，而像 Google 那样的公司，专职测试的研发能力较普通开发来说有过之而无不及（见 Google软件测试之道）。也正因为如此，如果一个团队的成员都比较优秀，再加上有比较出色的产品经理，那么拥有一支靠谱的跨职能团队也不是那么遥不可及的事情，他们能够每天直面用户，以小时为单位做出响应，因此在市场中有巨大的竞争优势。

对于一名普普通通的程序员（像我这样），应该如何面对这样的行业趋势？如何才能保持自己的竞争优势，不至于在40岁的时候被裁员、被淘汰？

首先是观念的转变，“程序员”或者“软件工程师”这样的头衔也许已经过时了，实际上我们应该是做服务的，这一点和开餐厅、开发廊没有本质的区别。唯有做到吸引更多的客户、让客户满意，才能保证组织的生存和壮大，也进而是我们自己的发展和壮大。怎样做才能吸引客户？才能让客户满意呢？那你得理解他，例如通过运维数据去理解；你得保证服务的质量，要保证可用性，保证功能正确；你得有创新，让客户眼前一亮。因此，你不仅要和机器打交道，你还要学会通过各种方法和客户打交道。

其二，在观念转变的基础上，有针对地拓展自己的技能。为什么要学习自动化测试？因为它能帮助我们提升软件质量，让客户满意；为什么要学习 DevOps 方法论和相关工具？因为它能让我们更快发布软件响应客户的需要；为什么要关注性能？因为客户是人，人的耐性是有限度的；为什么要关注可用性？因为客户是人，一般人如果遇到 Starbucks人满为患，它会去对面的 Costa 买拿铁的。

我无法想像20年后程序员后会用什么语言怎样开发软件，正如20年前也很少有人能想到今天移动互联网的如火如荼，也许届时程序员这个职业也会渐渐消失，但不论如何，我相信通过技术服务人的人性需求，这样的一个基本事实是不大可能发生变化的。

正文到此结束