Zalando曾公布过2019年时的微服务数量已经超过了4千支，这些微服务之间的关联可以画出一张复杂的关联图（如图左），它们自嘲说这看起来像是一张死亡之星图，任何一条线断了，就可能代表某个服务出状况。随著微服务的数量增加到数千只，「当时的管理层，做出了一个影响应用程式开发后的日常维运，非常重要的决定，那就是『自己打造的程式自己管。』（You build it,you run it.）。」Zalando前工程经理Andrew Howden指出。
在2015年时，欧洲大型电商Zalando拥有1万名员工，超过1千名工程师，200个开发团队。甚至，开发人力在2015年时只有600人，到了2018年，暴增到2,000人的庞大规模。
再一次的开发人力倍增，也让Zalando再一次遇到了挑战更大的开发复杂性协调课题。但这一次，Zalando决定找出一种够安全，又能让庞大团队更敏捷的根本解法。
Zalando找来30名最资深的工程师聚在一起，多次讨论后归纳出Zalando所面对的三大问题。
第一个问题是庞大的系统。随著业务成长和多国据点的扩张，Zalando的程式码越来越多，程式码间的关联也越来越复杂。新手工程师很难快速了解这套系统，得花上好几个月熟悉后，才能开始有生产力。而且，程式码数量越多，伴随的程式臭虫也越多，为了确保系统运作的安全，衍生了更多检查，再度拖慢了整体的开发速度。
第二个问题是系统间高度互联（Interconnected Systems）。过去，Zalando开发团队的目标是尽可能地优化每一个功能的执行速度，而不是简化系统。这么做的结果是，这些系统之间的相依性越来越高，也越来越难以预期和不直觉。任何一个系统的变动，都可能对其他系统产生连带的影响，增加了整体系统的脆弱性。
最后一项，30位资深工程师们共同提出的大问题是，Zalando用了「无聊技术」。当他们所用的技术越稳定、可靠，也代表了这些技术越老旧，就越让工程师感觉到无聊。
「这听起来不像是问题，但从人员招募角度来看，这是一个大问题。」参与Zalando最近4年SRE战略发展的第一线工程主管、Zalando前工程经理Andrew Howden如此坦言。
刚从大学毕业的年经工程师，兴奋地拜读了所有Google最新的部落格文章，上面介绍了最新的K8s、容器等云原生新兴技术，可是Zalando用的却是十年前的Java技术架构，很难引起年轻工程师的兴趣。
展开组织大变革，决定拥抱激进敏捷模式
「Zalando需要改变，需要彻底改变，我们将这种变革称为激进敏捷（Radical Agility）。」Andrew Howden表示，这真的是一次组织面的结构性变革。
这项变革策略的核心是，不再由单一大型业务单位主导决策，改由多个平行小单位，可以各自协调来决策。换句话说，等于是从序列式的决策流程，改为由平行的相关团队自己决定，不用照会其他无关的业务部门。这意味著，可以尽可能减少需要参与的沟通对象，来推出新的业务功能。
为了提高团队平行运作的能力，Zalando采取了新的所有权制度，定义了一种新的角色，称为专责所有权人（Dedicated owner），或者可用台湾社群熟悉的俗称「炉主」来形容，由这个人来负责一项业务的所有产品、成果、技术的主要决策，也由他负责监督所有状况的回报。
在供应端、需求端、数位体验、用户介面、数位基础设施的部门中都可以设立炉主这类角色。炉主有很大的自主权能选择要采取什么样的作法，但他得要对这个作法的成败负起全责。
炉主带领的团队采取了跨部门混合编组，找来这项业务上线所需的相关人力，包括开发人员、产品人员、法务、监控人力等。这些人背后都有各自所属部门的主管。例如开发人员背后还有开发部门的经理。
「以这种方式重组运作方式，就等于是重新组合沟通流程，立即遇到的问题就是，所开发的软体会受到什么影响？」Andrew Howden指出。
敏捷领域常参考的康威定律（Conway’s Law）提到一个观点，软体架构会受制于企业内部的沟通架构。Andrew Howden从另一个角度来看，他指出：「想要重新改变企业的沟通方式，就必须重新改变软体架构，否则它会自行发生。」
大力拥抱微服务，从100只到4千只微服务
所以，Zalando在技术上决定拥抱微服务架构，而在组织面，也将人员分为五、六人规模的小组，由每个小组负责一项微服务。对这个小组说，只需要负责这个微服务，其他的微服务不是你们的问题。
Zalando大力推动各项微服务的开发，从一百个服务，暴增到数千只，而且持续增加。Zalando曾公开过，在2019年，微服务总数足足超过了4千支。
新的挑战是，不能再靠人工团队的测试来确保软体发布的正常，而是得依赖大量的自动化测试，来验证相关系统的边界是否如常运作。
Zalando决定采取全新技术架构和组织架构之后，一开始还建立了一群待命值班团队，当时有3个待命团队来确保正式环境的运作。
一开始只有100项服务时，这个作法运作得相当好。但是，随著微服务的数量，增加到数千只，还要考量这些微服务间的互动，以及追踪这些服务随时间的演变，单靠3个值班团队，就没有能力应付了。「当时的管理层，做出了一个影响应用程式开发后的日常维运，非常重要的决定，那就是『自己打造的程式自己管。』（You build it,you run it.）。」Andrew Howden指出。
打造这只软体的开发人员需要负责这只软体的待命、维护基础设施、订定CI/CD流程等，任何将这只应用程式送到正式环境所需的一切事务，都由打造软体的团队来负责。
但这个决定，也让待命值班作法更加分散，开始影响到待命支援的品质。尤其有些协作经验不足的团队，遇到跨团队的工作时，就会出现责任推来推去，「这是你的问题」或「这不是你的问题」的争执。
另外，在基础架构管理上，也遇到新的挑战，为了让炉主负起全责，Zalando的作法是让每一个炉主有一个专属的AWS帐号，这就像是对他们说，「这个帐号就是你的信用卡，你可以做你认为对的事。」这种放权，有助于让开发人员打造了杰出、复杂又有趣的架构，但是，基础架构管理是一种专业，不能让擅长软体开发的工程师自己乱尝试。
打造集中式平台，让技术知识民主化，人人都能取得维运经验
尤其，Zalando的挑战是2千名工程师，超过1千套系统的规模，因此，「Zalando需要发展出一种做法，可以大规模地将知识民主化（Democratization of knowledge ），让人人可以取得正式系统运作的经验。」Andrew Howden表示，唯一的方法就是建立一个集中式的平台来分享知识，这正是平台团队可以发挥之处。
Zalando有一个「数位基础（Digital Foundation）部门」，为其他各单位提供一套通用的能力。
在2014年到2018年之间，这个数位基础团队发布了一些重要的内部产品，包括了像是应用程式注册表（Application Registry）、容器化平台服务（Docker-base platform as a service）、CI/CD机制、API探索及验证工具、开发者控制台等。
这个AP注册表服务的名称是Kio，开发团队在将自己打造的程式部署到正式环境之前，要先到这个集中式的AP注册表上登记，没有登记到Kio上的AP就不能部署。Kio服务也会提供一套指南，涵盖了各单位部署AP的相关指引。这个注册表提供了工程师详细查看各种业务和功能的索引，也有助于处理资安问题。
而容器化平台服务则用来执行容器、提供服务、保管映像档、支援部署、授权、凭证派发、产品存取控管、稽核和Log管理等。另外也用Jenkins伺服器建立了一系列CI/CD机制，后来更在Docker平台上，发展出了一套持续部署平台（Continuous Deliver Platform，简称CDP），负责处理在正式上线前的发布阶段的任务，像是映像档和二进位档验证、合规检查等。
另外还有一款API探索和验证工具，因为Zalando采取API优先（API First）的策略，开发工程师得采取Swagger工具来建立符合标准的API，在RESTful API和事件指南提供了相关API定义和验证。
最后一项的开发者控制台（Developer Console），这是一个内部网站，可以让开发人员查看自己的CI/CD工作流。
积极发展这些工具和平台，反映出，「这是Zalando第一次意识到开发者平台的重要性。」Andrew Howden指出。
2016年开始拥抱SRE
Zalando在2016年时，决定开始拥抱SRE（网站可靠性工程），成立了SRE团队。这一年也是Google发表《Site Reliability Engineering: How Google Runs Production Systems》 这本书的那一年。
Zalando先进行内部问卷调查，了解各团队对于SRE角色的期待，来凝聚所有人对SRE定位的共识，归纳出5项SRE的能力：SRE具有软体工程能力、维运思维、系统工程能力、软体架构技能和问题解决能力。这五大能力也成了Zalando建立内部人才库的重要方向，不只SRE，更用来要求各种技术角色的工程师，都要具备这五大能力。
接著，Zalando成立了第一个SRE团队后，第一件事就是设计SLI（服务水准指标） ，并且订出想达成的SLO（服务水准目标），还开发出一款SLO报表工具。同步也举办工作坊，对内部上百团队的产品PM和工程师介绍SRE，还在一年一度的网路购物周准备计划中，举办SRE工作坊，来讨论购物潮的各项网站可靠性设计。不过，第一次拥抱SRE，最后没有发挥原本预期的作用。
第一次导入SRE失利的原因
Zalando曾在工程部落格上公开了第一次SRE导入失败的主因，虽然搜集到大量的SLI指标维运数据，但是空有SRE数据， SRE团队没有善用这些维运数据来改善开发，也无法解决原本待命支援不足的问题。SRE导入一段时间后不如预期，Zalando高层决定暂时喊停。
原本Zalando按照产品丛集来建立SRE团队，一个团队负责一个丛集，一个SRE团队负责同一个产品网域下的所有维运责任。
后来，Zalando高层取消了原本在各产品下所设置的SRE团队，改将SRE工作交给各产品团队中的交付小组（Delivery Team）接手，让他们接手自己产品中关键服务的维运，要求产品交付团队必须具备SRE能力，来负责各自所负责的关键产品的待命工作。
虽然裁撤了SRE团队，但是Zalando没有停止采用SRE的实践，Zalando开始改良SRE工具和SRE做法，例如从产品管理层级来管理SLO的达成情况，而非监控微服务工程层级的庞大SLI指标数据，也不再用当机事件的指标数据，改用事件征兆来设计警示机制，还设计了新的事件处理流程，进一步区分不同的改善做法对顾客或是业务能带来的效益，优先采取更有利的做法。
Zalando也开始认真累积SRE维运指标的成效数据，来衡量这些指标是否符合指标设计的目标。
「当年，整体组织还没有准备好要以SRE方式来思考可靠性。」Andrew Howden事后回顾当年的考验。但他认为，更重要的一点是，「数位基础部门的设立，代表了Zalando真正开始重视开发者体验，成为企业优先考量的事。」