公司背景：塔吉特百货公司（英语：Target Corporation），总部在美国明尼苏达州的明尼阿波利斯，是美国僅次於沃尔玛的第二大零售百貨集團。在2010年财富500强企业排33，亦是标准普尔500指数成份股。Target也有非常庞大的IT组织，包括3个数据中心，数千名员工，以及从大型机到手持设备的复杂而分散的IT系统。

缘起：2012年

Target的DevOps之旅可以追溯到2012年。可以说是由一个对公司IT现状不满意的小组开始的，这就是Target的API开发小组。API是Target对获取内部数据如此复杂及耗时不满的一个替代尝试。但该小组-- 尤其是负责人HeatherMickman -- 很有理想，他们不仅希望提供统一的API接口供其他系统调用，而且还要用和原来不同的开发方法来完成，尤其是敏捷和DevOps的相关实践。所以从2012年开始，就有了第一次TargetIT对持续集成，基础设施暨代码，社会化编码，还有DevOps文化的探索。

2012年：开始从一个小组尝试一些DevOps的实践

几个重点：

·     从API开始可以说是开启DevOps的一个很好的选择，Heather 也认为基于服务的架构（Service First Architecture）是DevOps的基础。

·     把CI做好很困难，这里尤其涉及到思维习惯的转变。但这个是下一步的基础，所以他们花了几个月的时间建立起了这一习惯。CI的建立使该小组可以做到频繁发布。

·     关于基础设施暨代码：Target没有从容器开始（当时也没有），更多的是在版本控制系统里把生成和配置环境的代码维护起来，作为部署的一部分实践管理起来。

·     Social Coding（社会化编码）：这里指的是采用敏捷/DevOps里的相关实践，比如工作可视化，提交实践，还有Pull Request（而不是Push）等。

·     文化方面：强迫自己脱离舒适区，不断试错以及对失败的不同态度，不接受平庸的文化，划出10%的工作时间用来学习和尝试新技术新方法。另外，领导要保护好自己的组员，让他们可以自由创新，而不担心后果。

草根生长：2013年

到了2013年，之前一年这一个小组所做的尝试开始显现出威力。从开发出来API数量，API被调用的次数、范围，以及交付速度（每周10+次发布）上都在组织的更大范围内被注意到。

2013年：API团队成长及其所用实践被更多团队了解的一年

几个重点：

·     基于API项目的成功，该小组开始思考把API作为搭建企业系统的平台级调用而非只是数据读取接口。这样，采用版本管理的方式就不足够了，他们开始建立Target的OpenStack环境（目标：企业PaaS）。

·     持续优化部署实践。任何成为部署障碍的事情都是他们去解决的对象。经过后继四年的努力，他们的部署流程更加一致、安全并且可重复。

·     DevOps之火在其他小组开始蔓延：几个有远见的团队开始合作，一起推动DevOps实践。

声势初显：2014年

到了2014年，在这一年里，DevOps之火在Target开始真正燃烧。他们组织了几次组织内部分享大会，另外也专门为中高层经理开了专场，并请到了像GeneKim这样的业界大拿做嘉宾演讲。这使得企业高层开始重视，并给予组织层面的支持。

同样，Target也从企业走出去，积极参与外部相关社区活动，包括DevOpsDays，骇客大赛，2014年也是Target第一次参加DOES大会，此后三年他们年年都作为主讲嘉宾参加。这一做法也使得IT部门的招聘工作变得容易，因为技术人才都希望为新形态的企业服务。

2014年：新纪元的黎明– 广泛传播DevOps理念

另外这一年API团队自己本身的交付成果也来了一次大爆发。包括API数目达到30个，每周可以发布80多次，而在加发布次数增加的同时，事故(Incidents)数量却在下降，这和State of DevOps Report中的调查是一致的。这也使得该小组底气十足，用业务结果来说话，让公司高层看到DevOps不是一小撮技术极客的玩具，而是有实实在在的、巨大的业务价值。

到了2014年底，DevOps的一些实践已经在组织中很多团队被使用，而且也得到了管理层的认可，但还不是Target的企业级标准实践。2015年的一次人事变动，让企业级的DevOps成为现实。

高层全力支持：2015年

2015年Target迎来了新的CIO，Mike McNamara。Mike很惊喜地看到敏捷和DevOps实践在Target已经有了一定的群众基础，于是开始大力推广。这一次，Target终于把草根阶层里的DevOps提到了组织层面，要求Target的IT全部采用敏捷和DevOps，并给出最后期限：到2015年底，所有团队都必须是敏捷团队。同时，Mike推动组织架构调整，从项目导向的团队重组为产品导向的团队。

2015年：更多的改变– 架构模块化和向公有云迁移

重点：

·     Target从以项目导向的组织变成产品导向的组织，每个产品团队从端到端负责一个产品或服务的开发。这也是现在大多数采用DevOps比较成熟的组织的做法。

·     所有开发以及运维相关的实践全部向敏捷和DevOps转型，这是组织层面自上而下的决定。

·     更有计划有策略地设定IT优先级：比如花时间解决技术债，并把以前的巨石架构模块化。DevOps不再只是草根阶层随意性的实验，而是更有策略的集体行为。

·     全面拥抱公用云。

平台化、微服务化：2016年

到了2016年，由于组织架构向产品化团队的转型，API团队的任务也从提供数据调用接口转型成开发平台所需相关服务的开发和维护。这一点，笔者在以前服务过的客户身上也看到同样的转型。其实，就是建立企业自己的PaaS层应用，把底层的基础设施准备，环境配置，部署的发起等服务API化。

2016年：持续进步 – 基础设施平台化

重点：

·     不可变基础架构。这里就涉及到引入容器技术。

·     融合私有云和公有云，提供统一平台级接口和调用服务

·     增加监控相关的工具实施。

·     目标是为开发团队提供全部自我服务（self-service）的PaaS层功能。一个衡量指标是当一个新团队第一次采用该PaaS层服务后，有多快能够开始把代码发布到产品环境去。目标是2个小时。

·     微服务化。

Dojo – DevOps“道场”

最后重点介绍一下在Target非常成功的Dojo – DevOps“道场”。道场是一个浸入式学习、体验和实践训练，一般持续4~6个星期。某个想转型的团队会到一个专门的场地工作，有全职的敏捷教练或者DevOps导师全程指导。在这4~6个星期内，团战每天系统学习新的Agile，Lean和DevOps相关的方法、技术和工具，在有专人指导的情况下实践所学，并从实际的工作中学习成长。现在Target已经有三个专门的Dojo场地，分布在三个大的开发中心。这一“道场”训练，快速的帮助很多团队迅速转型，并能在最短时间内产生出理想的结果。

针对高管的一天DevOps“道场”

他们甚至还专门组织了给高管的1天快速“道场”，连CIO都要坐下来写代码。这一方式帮助一线员工和管理层之间互相理解，形成有效的透明、分享、持续学习的DevOps文化。

总结

总结下Target的DevOps转型之旅：

Target的DevOps转型之旅时间表

重点：

·     从为什么（Why）开始。DevOps是通过IT来提升企业的灵活性，竞争力和客户满意度。没有业务需求的DevOps很难成功。

·     有志者事竟成。不要过多担心你的企业是不是具备转型条件。事实证明，这些所谓的条件都是人创造出来的。从自身和自己的团队做起，用星星之火，可以燎原的心态来做。

·     开始的时候不一定要有个宏大的DevOps计划，先从一两个团队开始，做出成绩，并用成绩说话。

·     要有包容的心态，不要把DevOps变成一个小群体的玩具。积极传播、影响和吸引更多的人进来学习、实践。并且从中成长。DevOps文化的本质是开源文化。

·     DevOps技术实现的路径并不绝对。比如Target就是在2016才开始容器的应用，而前几期讲到的KeyBank在实践DevOps一开始就把容器的应用作为重点。

·     浸入式的“DevOps道场”对组织快速转型起到了很重要的作用。“道场”给DevOps的理论学习和实践提供了一个完美结合的空间。企业要发起大规模转型的时候可以考虑。

·     高层的支持不是DevOps启动的必要条件，但要形成组织层级的行为，这一支持甚至推动是必不可少的。

Target可以说是传统企业向DevOps转型的代表。从草根开始，最后完全改变了企业的数字DNA，完全是开源的精神原则。可谓DevOps转型不论出身，只有你想不想做。（许峰原创）

公司背景：塔吉特百货公司（英语：Target Corporation），总部在美国明尼苏达州的明尼阿波利斯，是美国僅次於沃尔玛的第二大零售百貨集團。在2010年财富500强企业排33，亦是标准普尔500指数成份股。Target也有非常庞大的IT组织，包括3个数据中心，数千名员工，以及从大型机到手持设备的复杂而分散的IT系统。

缘起：2012年

Target的DevOps之旅可以追溯到2012年。可以说是由一个对公司IT现状不满意的小组开始的，这就是Target的API开发小组。API是Target对获取内部数据如此复杂及耗时不满的一个替代尝试。但该小组-- 尤其是负责人HeatherMickman -- 很有理想，他们不仅希望提供统一的API接口供其他系统调用，而且还要用和原来不同的开发方法来完成，尤其是敏捷和DevOps的相关实践。所以从2012年开始，就有了第一次TargetIT对持续集成，基础设施暨代码，社会化编码，还有DevOps文化的探索。

2012年：开始从一个小组尝试一些DevOps的实践

几个重点：

·     从API开始可以说是开启DevOps的一个很好的选择，Heather 也认为基于服务的架构（Service First Architecture）是DevOps的基础。

·     把CI做好很困难，这里尤其涉及到思维习惯的转变。但这个是下一步的基础，所以他们花了几个月的时间建立起了这一习惯。CI的建立使该小组可以做到频繁发布。

·     关于基础设施暨代码：Target没有从容器开始（当时也没有），更多的是在版本控制系统里把生成和配置环境的代码维护起来，作为部署的一部分实践管理起来。

·     Social Coding（社会化编码）：这里指的是采用敏捷/DevOps里的相关实践，比如工作可视化，提交实践，还有Pull Request（而不是Push）等。

·     文化方面：强迫自己脱离舒适区，不断试错以及对失败的不同态度，不接受平庸的文化，划出10%的工作时间用来学习和尝试新技术新方法。另外，领导要保护好自己的组员，让他们可以自由创新，而不担心后果。

草根生长：2013年

到了2013年，之前一年这一个小组所做的尝试开始显现出威力。从开发出来API数量，API被调用的次数、范围，以及交付速度（每周10+次发布）上都在组织的更大范围内被注意到。

2013年：API团队成长及其所用实践被更多团队了解的一年

几个重点：

·     基于API项目的成功，该小组开始思考把API作为搭建企业系统的平台级调用而非只是数据读取接口。这样，采用版本管理的方式就不足够了，他们开始建立Target的OpenStack环境（目标：企业PaaS）。

·     持续优化部署实践。任何成为部署障碍的事情都是他们去解决的对象。经过后继四年的努力，他们的部署流程更加一致、安全并且可重复。

·     DevOps之火在其他小组开始蔓延：几个有远见的团队开始合作，一起推动DevOps实践。

声势初显：2014年

到了2014年，在这一年里，DevOps之火在Target开始真正燃烧。他们组织了几次组织内部分享大会，另外也专门为中高层经理开了专场，并请到了像GeneKim这样的业界大拿做嘉宾演讲。这使得企业高层开始重视，并给予组织层面的支持。

同样，Target也从企业走出去，积极参与外部相关社区活动，包括DevOpsDays，骇客大赛，2014年也是Target第一次参加DOES大会，此后三年他们年年都作为主讲嘉宾参加。这一做法也使得IT部门的招聘工作变得容易，因为技术人才都希望为新形态的企业服务。

2014年：新纪元的黎明– 广泛传播DevOps理念

另外这一年API团队自己本身的交付成果也来了一次大爆发。包括API数目达到30个，每周可以发布80多次，而在加发布次数增加的同时，事故(Incidents)数量却在下降，这和State of DevOps Report中的调查是一致的。这也使得该小组底气十足，用业务结果来说话，让公司高层看到DevOps不是一小撮技术极客的玩具，而是有实实在在的、巨大的业务价值。

到了2014年底，DevOps的一些实践已经在组织中很多团队被使用，而且也得到了管理层的认可，但还不是Target的企业级标准实践。2015年的一次人事变动，让企业级的DevOps成为现实。

高层全力支持：2015年

2015年Target迎来了新的CIO，Mike McNamara。Mike很惊喜地看到敏捷和DevOps实践在Target已经有了一定的群众基础，于是开始大力推广。这一次，Target终于把草根阶层里的DevOps提到了组织层面，要求Target的IT全部采用敏捷和DevOps，并给出最后期限：到2015年底，所有团队都必须是敏捷团队。同时，Mike推动组织架构调整，从项目导向的团队重组为产品导向的团队。

2015年：更多的改变– 架构模块化和向公有云迁移

重点：

·     Target从以项目导向的组织变成产品导向的组织，每个产品团队从端到端负责一个产品或服务的开发。这也是现在大多数采用DevOps比较成熟的组织的做法。

·     所有开发以及运维相关的实践全部向敏捷和DevOps转型，这是组织层面自上而下的决定。

·     更有计划有策略地设定IT优先级：比如花时间解决技术债，并把以前的巨石架构模块化。DevOps不再只是草根阶层随意性的实验，而是更有策略的集体行为。

·     全面拥抱公用云。

平台化、微服务化：2016年

到了2016年，由于组织架构向产品化团队的转型，API团队的任务也从提供数据调用接口转型成开发平台所需相关服务的开发和维护。这一点，笔者在以前服务过的客户身上也看到同样的转型。其实，就是建立企业自己的PaaS层应用，把底层的基础设施准备，环境配置，部署的发起等服务API化。

2016年：持续进步 – 基础设施平台化

重点：

·     不可变基础架构。这里就涉及到引入容器技术。

·     融合私有云和公有云，提供统一平台级接口和调用服务

·     增加监控相关的工具实施。

·     目标是为开发团队提供全部自我服务（self-service）的PaaS层功能。一个衡量指标是当一个新团队第一次采用该PaaS层服务后，有多快能够开始把代码发布到产品环境去。目标是2个小时。

·     微服务化。

Dojo – DevOps“道场”

最后重点介绍一下在Target非常成功的Dojo – DevOps“道场”。道场是一个浸入式学习、体验和实践训练，一般持续4~6个星期。某个想转型的团队会到一个专门的场地工作，有全职的敏捷教练或者DevOps导师全程指导。在这4~6个星期内，团战每天系统学习新的Agile，Lean和DevOps相关的方法、技术和工具，在有专人指导的情况下实践所学，并从实际的工作中学习成长。现在Target已经有三个专门的Dojo场地，分布在三个大的开发中心。这一“道场”训练，快速的帮助很多团队迅速转型，并能在最短时间内产生出理想的结果。

针对高管的一天DevOps“道场”

他们甚至还专门组织了给高管的1天快速“道场”，连CIO都要坐下来写代码。这一方式帮助一线员工和管理层之间互相理解，形成有效的透明、分享、持续学习的DevOps文化。

总结

总结下Target的DevOps转型之旅：

Target的DevOps转型之旅时间表

重点：

·     从为什么（Why）开始。DevOps是通过IT来提升企业的灵活性，竞争力和客户满意度。没有业务需求的DevOps很难成功。

·     有志者事竟成。不要过多担心你的企业是不是具备转型条件。事实证明，这些所谓的条件都是人创造出来的。从自身和自己的团队做起，用星星之火，可以燎原的心态来做。

·     开始的时候不一定要有个宏大的DevOps计划，先从一两个团队开始，做出成绩，并用成绩说话。

·     要有包容的心态，不要把DevOps变成一个小群体的玩具。积极传播、影响和吸引更多的人进来学习、实践。并且从中成长。DevOps文化的本质是开源文化。

·     DevOps技术实现的路径并不绝对。比如Target就是在2016才开始容器的应用，而前几期讲到的KeyBank在实践DevOps一开始就把容器的应用作为重点。

·     浸入式的“DevOps道场”对组织快速转型起到了很重要的作用。“道场”给DevOps的理论学习和实践提供了一个完美结合的空间。企业要发起大规模转型的时候可以考虑。

·     高层的支持不是DevOps启动的必要条件，但要形成组织层级的行为，这一支持甚至推动是必不可少的。

Target可以说是传统企业向DevOps转型的代表。从草根开始，最后完全改变了企业的数字DNA，完全是开源的精神原则。可谓DevOps转型不论出身，只有你想不想做。（许峰原创）