又一个交付故事:技术决策的迷局

上一个故事是关于自治团队解放生产力的,除了生产力之外,交付的另一个关键因素是软件架构,架构是在软件开发过程中并不那么容易改变的东西。然而与过去时代所不同的是,今天的软件架构并不是所谓的架构师高高在上做出的一些决策后就不再改变了,在这个技术快速变化的时代,今天的架构更像是在时间线上一系列的轻量技术决策积累的一个结果。

而这个故事,就是关于技术决策的。

明线:所有权?经营权?决策权?监督权?

与A记不同的是,我们的客户C记并没有自己的IT团队,也没有一个明显的IT部门。与C记的合作时间就更长了,这么长久的合作过程,却是从一段“黑历史”开始的。

在2009年到2010年的时候,C记项目上一个技术决策的过程基本上是这个样子的:客户说,“我们只能用SQL Server”。我们听到这个消息之后,一方面在心里暗想,“为啥要选SQL Server,为啥喜欢微软”,另一方面,我们发现,客户并没有提究竟用什么 ORM 框架,于是便“我们自己搞一个吧”。接下来发生的事情是,我们自己搞出来了一个NoSQL的文档数据库嫁接在SQL Server之上。从这个项目上线的第一天起,就开始被打脸:性能问题,维护成本,数据迁移的难度,我们花了非常大的代价,才让这套东西基本上能够工作。

在那段时间里,这并不是唯一一个“鲁莽的“技术决策,而这一切到底是如何发生的?实际上,存储框架的决策比起采用什么样的数据库来说,要重要的多,然而这样重要的决策却没有被拿到桌面上正儿八经的和客户一起讨论。我们并不是糟糕的工程师,然而我们却把自己的才智与精力放在了错误的地方。

没有业务的引导,技术决策就更“技术导向”而不是“业务导向”。

我不得不给客户写一封邮件来解释为什么我们要花很大的代价,从一个 homemade 的存储框架,切换到更加成熟的方案,而我直到现在依然可以很清楚的记得当时的尴尬。

客户当然非常不高兴,最后的回复是,“至少我们开始讨论这些事情了”。于是这正是我们开始做的,我们开始在作出重要技术决策的时候邀请客户参与。设置一个技术治理小组,每个月对技术方向进行讨论,用技术债雷达来可视化和积极的应对技术债,这些都是在客户的参与下发生的。

一方面,这是为了把更多的信息透明给客户,然而更为关键的另一方面是,为了作出慎重的技术决策,我们需要知道客户所面临的约束,我们需要能够从中验证自己的假设,从而更好的尊重这些约束。

Tech Lead 的倾向从追逐”正确“的决策,变成了开始作出”合适“的技术决策。

于是事情开始向好的方向发展,从2011到2014年期间,homemade 的存储框架的搭桥手术成功,能够让我们逐渐迁移到成熟的方案;我们开始构建了更多的产品,微服务的技术架构也逐渐成型;随着新系统的上线和老系统的退休,整个平台迁移到了RackSpace上,加上自动化部署流水线,发布变得越来越频繁。

Happy ending?可惜并不是,2014年,客户方的技术负责人被调动到了另一个部门,另一个人接手了他的工作。与前任不同的是,他对于技术决策的参与度非常高。甚至有时候会为团队做决策,然后让团队承担决策的后果。

这导致了另一个问题,当团队所得到的只是一个决策结果,没有一个重新思考和衡量约束的过程,团队无法在不断变化的技术环境中持续的验证以前的假设。一方面,我们丧失了很多采纳新技术的机会,更重要的是,团队需要能够自己做出决策,承受自己决策的后果,并从中自己的决策中学习和成长。

于是我们建议客户能够更多的分享上下文,而不是做决策,决策由团队来出,但是客户保留否决的权力。如果客户不认可决策,在分享了原因之后,团队可以更好的提出别的方案。

去年C记的团队成功交付了一个新的产品,替换掉了好几个花了三年多时间开发的老产品。由于大多数的功能都已经服务化,所以新产品的开发只花了半年多时间就上线了。用客户的话说,我们“able to leap tall buildings in a single bound”。这是正确的技术决策压过了错误技术决策之后的结果。

聆听、理解和尊重客户约束,在技术决策上谨慎的前行,同时,随着技术的发展不断去反思和检查这些约束假设是否依然成立,从而持续的保持技术架构演进的方向与业务能力的对齐。

这是C记的故事的明线。

暗线:寻找时间之矢

有意思的是,如果倒过来读C记的故事,会发现如果加以打磨,依然可是一个好故事:刚开始的时候,客户强控制技术决策,我们很suffer,然后,慢慢信任,逐渐放弃控制,最后,我们赢得了客户的信任,开始独立做决策,happy ending。虽然并不真实,然而却是一个更好的故事。

这就如同物理学定律中,时间是对称的一样,决策机制在这个故事中,也是时间对称的,那么决策机制就并不是进化的关键因素。然而在物理学中,熵增却是时间之矢的指向,那么这里的时间之矢到底是什么?

郭晓的演讲中,我找到了想要的答案。

就如同交易成本的不断降低,打破了壁垒,促进了无数的人投身创业一样,技术成本的不断降低,技术壁垒的不断降低,也会带来更大范围的结构性变化。

比如说自动化测试技术干掉了传统的测试部门,数据库的自动化技术干掉了DBA,部署、运营的自动化干掉了运营,云化、安全内嵌也许将要干掉采购和安全。当这些东西,因为技术的进步而标准化后,当全面的数字化平台in place之后,那么剩下的就仅仅是业务解决方案、技术栈与实现代码了,在这个画面里,不写代码的传统IT部门的麻瓜们是掺和不进来的,于是把决策权交给开发团队是一个自然而然的选择……

“If IT decision makers aren’t making the decisions any longer, who is calling the shots? The answer is developers. Developers are the most-important constituency in technology. They have the power to make or break businesses, whether by their preferences, their passions, or their own products.”——The New Kingmakers: How Developers Conquered the World

于是随着开发团队的权力越来越大,意味着更大的责任,在这种新形势下进行技术决策保障也需要转变思路。建立共同愿景,让团队找到自己为了什么来工作的理由,找到自己的 purpose,把自己与日俱增的 power 用到合适的地方,这才是作为技术领导者应该做的工作。

那么我们C记的故事的暗线也就浮出了水面,故事中所建立起的决策机制本质上是在营造安全感,我们的传统企业客户多多少少都有类似的决策机制(所谓的架构组),说白了是用增强控制来应对新形势下的心态失控。

然而,能控制得了的东西却越来越少,技术之矢使控制本身越来越没有价值,反而成了阻碍和包袱。在IT部门灭亡之前,也许就如同我们与C记故事的后半段一样,在事情变好之前,会先变坏,但熵增的车轮,是不会停下的。

也正是这种反抗之力如此顽强,每每当传统企业想要甩掉包袱往前快跑的时候,重重的阻碍却并不来自于领导层。透过传统企业繁冗的流程和层级,背后是一个个“企业架构师”、“系统架构师”,一个个在这样一种新的形势下即将“被干掉”从而失去自己职业发展的人。

那么,你现在的职位是什么呢……


更多精内容,请关注微信公众号:软件乌托邦

Share

一个交付故事

引子:技术带来的新挑战

如果我们回到2005年,我们所交付的软件基本长这个样子:一个框架、一个数据库,也许有一些OLTP的过程来支持报表功能。那个时候,Web2.0是当时的Buzz Word,jQuery还非常时尚。每半年或者一年,有一个发布的流程把这样的一个软件包部署在几台Server上。

今天,这样的软件系统依然存在着,然而,下面这幅图所展现的才是一个更加典型的软件系统。我相信在这幅图里,一定有什么东西已经不复存在了,因为每隔几个月,就会有新东西出现。ThoughtWorks技术雷达是从2011年开始发布的,我记得当时的雷达上只有30多个blip,然而看看今天的技术雷达,这个数字已经上升到了足足100多。

这产生了一个非常有趣的趋势,使用每一个具体的技术来构建应用变得越来越容易,然而具体的技术本身的生命周期却越来越短,这导致了整体复杂度的上升,而这种新的复杂度,带来了与以往不同的挑战。

引入新的技术,有时会带来新的做事方法,有时会带来结构上的冲击;整体复杂度升高,带来的另一个问题是决策点越来越多,在不断变化的技术选择中做出决策是另一个挑战;由于技术的生命周期越来越短,技术会以更快的速度过时,如何从这样的遗留系统中走出来也是一个挑战。

有意思的是,这样的挑战,在我们经历过的长期项目上,都有非常明显的体现。

第一个故事:自治团队的演化

我们与A记之间的故事是从2010年底开始的,那时候,所有的团队在本地做构建,然后把RPM包发给运维团队,运维团队把RPM包部署到数据中心里去,部署过程基本上是手动完成的,开发团队与运维团队完全分离。

当时,虽然“持续交付”的概念已经提出来了,然而市场上并没有特别成熟的工具支持,有一次为了做个集成测试,整整花了3个月才把环境准备好。这个过程实在是太痛苦了,于是在2011年初,我们的一个团队开始用puppet/chef和shell脚本构建持续部署流水线,其实也就是两个人。也是因为看到了自动化的价值,于是A记开始评估是不是要上AWS。

从2012年到2013年,AWS来了,每个人点几个按钮就能申请一台机器,于是突然间,每个团队都开始构建自己的自动化部署能力,持续集成流水线的产物,也从RPM变成了AMI,而这种技术的采用导致了一个很有意思的现象。因为大多数的部署步骤全都嵌入到了持续集成流水线里,维持一个臃肿的运维团队就变的完全没有必要了。于是为了更好的推广自动化能力,每个开发团队“嵌入”了一个运维,与开发团队一起自动化部署流程。发布的流程也变的非常简单,只有两个人负责所有团队的发布工作。

到了2014年,终于A记几乎将所有的系统全都迁移到AWS上了,几乎所有的团队都开始使用CloudFormation来管理基础设施。这又导致了一个很有意思的现象,因为环境准备和部署的流程通过更成熟的工具完全自动化了,软件的发布变成了一次按钮点击,一个中心化的发布过程也变得没有必要了,这个责任就“去中心化”的落到了每一个团队自己的头上。

“Who builds it, who runs it. ”这样的理念催生了更加自治的团队,创造出了更强的响应力和责任感。开发们开始自发地用更加标准的方式来写log、更加关注系统的监控、更自主的诊断线上问题。于是发布周期大幅缩短,从月度发布到每周都能发布。再加上微服务架构的采用,让团队的结构再一次发生了变化。

团队变的更小,运维完全本地化到了团队里,开始一起做story。跨团队的知识共享由一个个的虚拟团队负责,这种spotify的团队结构,一方面把权责都交给了开发团队从而减少组织摩擦;另一方面,实践与治理的方案也更多的作为上下文跨团队进行分享,而不是自上而下的推进执行。

从2015年到2016年,Docker来了。除了大幅提升打包和部署的速度之外,更重要的是,开发与生产环境之间的不同进一步被消弥,部署的编程模型变的更加简单,而这为标准化部署方式提供了机会。A记的架构组推出了一个基于docker的工具,基于提供了的抽象层,把部署相关的实践和工具全都抽离到了开发过程之外。

于是,开发团队只需要专注于开发cloud-native的应用,部署相关的过程全都交给了统一的工具来处理。之后的效果是显著的,从2015年到2016年,AWS上服务的个数增长迎来了巅峰,A记也终于做到了随时都能部署,新的功能几分钟就能上生产环境。

我们与A记之间故事的明线是团队结构的不断变化,然而背后的暗线,却是技术趋势以及所带来的影响。在采用新技术的同时,调整团队结构,给予团队更大的自治,从而释放生产力,这是高效交付的秘诀。

故事依然还在继续,总是有新的挑战在前方。因为市场的压力,A记一方面需要进一步通过标准化来降低成本,另一方面,也需要拓宽自己的产品范围来赢取更多新的客户。这个挑战是所有成功的公司都正在面临的。

新一期的ThoughtWorks技术雷达里,提出了“The Rise of Platform”这样的概念,每个成功的互联网公司都有一个基础平台来更好支撑和实施自己的业务战略,这正是现在A记想要前去的方向。而平台思维的关键并不是如何吸引开发人员,更多的是把开发者当作平台的客户,专注在如何提升开发团队的体验、关注在如何打造一个平台来为开发团队提供更多的自治,从而释放出更大的生产力。

随着开发团队有了越来越大的自治权,随之而来的是更大的责任,如何保证这种力量发挥在正确的地方,就是下一个故事了。


更多精彩内容,请关注微信公众号:软件乌托邦

Share

Software is Worthless

在一个周六的晚上,同事的一段文字让我思绪万千,沉寂了十几年的写作冲动,就这样被这段文字唤醒了,虽然已经0点过半。

不断萦绕在我脑中的一个思考:为什么越是痛苦压抑,越是能够产生富于生命力和创造力的文字;越是写意轻松,产生的却是浮躁且没有灵魂的声音。已经忘记是在哪里看到过这样一篇文字,叫做“历史的终结”,大概的意思就是,当故事走向幸福道路的时候,历史就在此刻终结了,因为幸福的故事已经不需要被表达与陈述。

1-wave-with-wind

“每一个幸福的家庭都是相似的,而每一个悲惨的家庭都有各自不同的悲惨”,这给出了一个可能的解答。痛苦是多样化的,而多样化正是生命力与创造力的源泉。在痛苦的挤压下,在那一丝丝的罅隙中奋起抗争,产生的是生命力与创造力;在约束的束缚下,在那一点点的空间中辗转腾挪,浮现出的却是富于生命力与创造力的设计。

软件便是这样,它是在问题与约束的罅隙中,纯粹脑力挣扎的产物。然而软件却又不同于文学作品,文学作品的运行时环境是人的大脑,大脑极强的适应性使得文学作品的价值可以世世代代的延续下去;然而软件的运行时环境是机器,其价值在几十年甚至短短几年里便会消耗殆尽,软件是短命的。

2-meteor

一个又一个新的javascript框架产生了,主流技术栈变得越来越相似,轮子在不同的语言和框架中一遍又一遍的被重复发明着,软件总是被淘汰与替换着。

自软件诞生起,就以惊人的速度不断降低着自己的构建成本,随着软件开发技术的不断革新,今天大多数的商用软件,本质上都是基于开源软件的二次开发而已,各种PaaS平台的兴起,进一步让软件的构造变的越来越容易。

想想你所写的每一行代码,将会以多快的速度被淘汰、被替换、被遗忘?越来越多的公司纷纷开源了自己的核心软件资产,让软件成为一种吸纳人才的手段,这些公司的核心竞争力越来越不在于软件本身。

软件生来便是短命的,越来越容易构造,就会越来越快的被替换和淘汰,也不会有太多公司以软件作为核心竞争力——Software is Worthless,即使不是现在,也就在不远的将来。作为软件的从业者的我们,整天疲于奔命学习新技术的我们,又应当用什么来衡量自我的价值?这一切的意义何在?

3-it

好吧,可能这个问题现在还不重要,在软件变的越来越容易构造、生产成本越来越低的时候,我们的工资却在不断攀升,在这样的一个软件人才供需极度不平衡的市场上,散发着软件要吃掉整个世界的信号,也许幸福的日子还能持续很长一段时间。可惜幸福与工资并没有太大的关联关系,所以历史也并未在此终结。

回顾我自己这些年的技术生涯,所做过的大大小小的项目,几乎都有着各自的悲惨,无论是成功的、失败的,都谈不上令人满意。所做过的技术决策,随着技术的革新,无一例外都是错误,若是以结果来衡量软件开发本身,一定是“人终有一死”。然而我的感觉却没那么糟,因为我更相信自己能够在新的环境下,更好的认清楚自己要解决问题,更好的搞清楚约束是什么,更好的保持开放心态、同时谨慎前行。除此之外,我却找不到任何一个与技术相关的词汇来描述自己的收获。

软件的本质是知识工作,而软件开发的过程,就是学习与成长的过程,过程的重要性是要远大于结果的。我们在尽力打造更好软件的同时,也打造了更好的自己。

思绪渐渐飘到了3年前,在我对自己的技术生涯感到迷茫的时候,一位在硅谷干了二十多年,在公司干了一圈管理又回到技术岗位的同事对我说:“写程序之于我,就好像是空气和水一样不可或缺,我觉得你应该和我是一样的”,面对这句话的时候,当时的我无法回应。然而在脱离技术岗位1年多,又重新开始做技术的今天,我却想回到那个时间点,回答说“是的,我也是一样。”

除了意识到自己对编程如此热爱之外,还体会到这个比喻中蕴含的更深刻的含义。
我们应当如何去衡量水的价值?我们又如何去衡量空气的价值?我们如何去衡量软件的价值?衡量知识的价值?衡量自我的价值?

今天,软件就如同空气和水,覆盖着我们生活的方方面面,变成了我们无法缺少的东西。当这个世界上,水需要去买,也许在某种程度上说,空气也需要去买的时候,难道不能引起你的反思,反思这个世界是哪里出了问题?这一切,都让我想起了互联网、黑客、开源精神,还有 Aaron Swartz……

4-hacker

在我们打造更好软件的同时,打造更好自己的同时,也许还有一个更远的远方在召唤着我们。

Share