[size=100%]赵成，蘑菇街技术总监，资深DevOps和运维专家，专栏作家，著有《进化：运维技术变革与实践探索》一书，腾讯云TVP，现任蘑菇街集团技术总监。

[size=100%]TOP100组委会：赵老师您好，非常荣幸能采访到您！赵老师是运维专家又是资深DevOps，是什么让您从传统运维走向DevOps？可否为大家介绍一下您的从业经历？

[size=100%]赵成：专家和资深，更多是外部对我的称呼。我觉得最重要的是一个人在职场上是否可以脚踏实地的解决实际问题，帮助公司成长。回到问题上，我认为传统运维和DevOps之间并没有什么严格的界限。这个转变更多的还是跟随软件架构的演进，一步步发展过来的，或者准确的说，软件架构发展的同时，也给运维带来了更多的发展空间。

[size=100%]我早期在华为负责的电信软件产品更多的是单体或分层架构，少部分是服务化架构。这些软件迭代周期比较长，并且遵循严格的IPD研发流程，因此，上线后的软件质量一般都相对可靠。所以在这种情况下，一线运维的同事关注的焦点更多的是在硬件和系统层面，只需要将系统层面的事情运维好即可。

[size=100%]但是随着互联网行业的高速发展，服务化、分布式、微服务这样的软件架构被广泛采用，运维所面临的问题就变得完全不一样了，软件模块，也就是我们常说的应用数量突然变多，变化频繁（每天发布），所以作为运维，要关注的焦点自然会偏移到应用层面。这种新的场景必须要有新的解决方案去应对，于是DevOps、SRE等优秀的理念和实践也就诞生了。而传统运维和DevOps之间的转变就顺其自然地发生了。

[size=100%]所以，总结下来就是我的第一句话所表达的意思：不管是做开发，还是做运维，需要时刻拥抱变化，脚踏实地解决每一个问题。

[size=100%]TOP100组委会：综合您的从业经历 ，能否简单为我们讲述下您认为传统运维和DevOps运维的主要的异同点在哪里？可否结合您在蘑菇街的实战经历为大家做相关介绍？

[size=100%]赵成：传统运维更加关注物理设备层面的维护，但是DevOps会更加强调应用层面的运维。或者准确说，是需要具备从应用的视角去做运维的思路。

[size=100%]由于软件架构的演进以及云计算行业的飞速发展，底层的基础设施被做的越来越完善。你会发现越底层的东西变得越来越标准化，比如阿里云的ECS和AWS的EC2，从使用的角度来说，其实差别并不大。这就给传统运维带来了很大的挑战，除了上面第一个问题中提到的场景挑战，还有两个主要的挑战：一个是发展空间受限；另一个是岗位需求量在趋于萎缩。所以，在思路上做转变在职责上转型就很必要了，或者更准确的说是面对新的场景，不得不转，这是个倒逼的过程。

[size=100%]从蘑菇街的经验来看，我们当时转型的时候，一方面从大厂招聘有经验的应用运维比如从阿里等，来作为经验的输入；另一方面不断向外部学习，看别人是怎么做的。最后就是我们自己去摸索实践。当时我们内部制定了一个原则：一定要站在开发和业务的角度解决实际问题。从实际问题出发的好处之一就是不会被各种理念、概念和技术搞的云里雾里，也不会不知从何入手。所有的技术应用都是为了解决问题。依靠这个原则去做事情也会更脚踏实地一些。

[size=100%]在转变的过程中，前期会痛苦些，因为根本找不着北。但是一旦摸到了方向，并坚持做下去就会越来越有感觉，越来越知道自己应该做什么。方向对了，路再远也不怕。

[size=100%]TOP100组委会：在蘑菇街运维成功转型后，稳定性依然是考验运维部门运维状况的一个重要指标。为了达到这个目标，团队需要未雨绸缪做哪些准备呢？

[size=100%]赵成：简单来讲，要从意识入手、形成标准、再到文化建设。这是一个体系性的工程。

[size=100%]之所以从意识入手，其原因是在一开始甚至是稳定性建设过程中，我们的工具和体系有时候还不够完善。此时我们很难直接依赖技术手段来保证系统稳定，很多变更操作也没法一下子全部通过自动化的工具完成。

[size=100%]在这个阶段，为了避免一些重大、低级、人为的失误，就需要在意识上进行加强。最简单有效的方式就是制定高压线。制定高压线就是规划好底线，触碰底线就要受到处罚。比如白天不允许操作网络设备，不允许做大表变更、不允许做拔插网线等操作。虽然看上去好像不是那么高大上，但是往往最有效，可以避免很多低级失误造成的严重故障。

[size=100%]其次是高压线一旦制定出来，就要把它变成一种习惯。当每个人对线上的敬畏心理形成后，高压线的震慑力就显现出来了。别说高压线不敢碰，就是一般的电线和电源在处理之前，都需要掂量下这种操作是不是有危险。所以，在很多流程规范约束不到的地方，这种方式就可以起到很好的补充作用。

[size=100%]2015年我到蘑菇街的时候，有一段时间故障频发。虽然我们制定了各种很细节的流程规范，但这些规范的效果并不好。后来就制定了高压线，简单易记，并且约定一旦违反就要受到处罚。通过此种方法，我们基本可以避免较大的故障。其实这其中的关键是人一旦形成意识并主动思考，就会主动规避风险。而如果是被动执行，那么有时候往往就不会考虑这么全面。

[size=100%]这个话题比较大，关于标准和文化部分，我先不展开讲了，这是我12月份演讲的主要内容，大家可以关注我的演讲。

[size=100%]TOP100组委会：Google SRE的理念如今大行其道，请问这套理念的核心关注点是什么？和国内运维团队的运维理念有何异同？

[size=100%]赵成：首先SRE(Site Reliability Engineering)是指站点可靠性工程师，最初由Google提出并实施推广。SRE的主要职责是保证站点的可用性，因为他需要对站点系统、组件节点、服务调用等较为熟悉，并需要关注生产的服务状况。在Google SRE中还提出了SLI，SLO，SLA的机制。我认为以下几点是这套理念的核心关注点：

[size=100%]1.SLO稳定性标准。根据系统运行的实际情况来设定合理的指标范围。SRE设定了SLO之后，无论开发、运维还是管理者都必须遵照这套标准处理问题。

[size=100%]2.50%原则。这一点主要强调SRE并不能被琐事缠身。无论他多忙，都要有50%的时间用来开发工具，从而解决重复的琐事。从另外一个角度，这也说明SRE更加强调技术解决问题，而不是靠管理以及流程之类来保证系统稳定性。

[size=100%]3.事后总结。Google非常重视从故障案例中总结提取经验，从而找到改进措施。我之前也提到过：故障永远是表象，背后的技术和管理问题才是本质。当这些问题积累到一定程度就会爆发出来。因此，故障最能够体现一个团队的技术和管理能力，也能暴露现存的问题。所以我们可以从中了解到：案例学习是一种非常简单且有效的提升手段。

[size=100%]4.No Blame文化。这一点主要是指就事论事，永远不要指责、抱怨团队和队友。只有在这样的环境下，大家才能敞开心扉，并且真正站在如何改进的角度去考虑问题、去解决问题，而不是担心自己被指责、被处罚。

[size=100%]这四个点，也将是我在这次大会演讲中分享的观点，欢迎大家关注。

[size=100%]TOP100组委会：听闻蘑菇街业务已开始全面上云。为什么蘑菇街要由原来的技术自主可控转变为与公有云厂商共同合作，走上全面上云之路呢？

[size=100%]赵成：我们依赖的是公有云厂商的基础设施和基础服务发展。这里主要有两个原因：

[size=100%]第一个是基础设施和服务越来越趋于标准化。无论是虚拟机、网络、数据库，还是软件层面的分布式缓存、对象存储、消息等，这些都已经非常标准通用了。这些产品在大的云厂商公有云服务上都有很长时间的运行和使用，所以既然已经有现成的服务了，为什么自己还要再重复造轮子呢?

[size=100%]第二个点是基础设施和分布式服务的搭建和运维较为复杂。技术难度和复杂度曲线在大规模应用的场景下会变的异常陡峻。因此需要有持续的、规模性的专家人力投入。对于一般企业来说，这项投入消耗太大，靠自己力量去投入实施不太现实。而且即使自己做，也不见得比业界厂商做的好。所以从这个角度出发，我们就更没有必要自己去做了。

[size=100%]我们会将更多的精力专注在业务技术发展上，让技术更多地为业务创造价值。

[size=100%]TOP100组委会：蘑菇街整体业务上云一定经历了很多事情，现在许多公司也有上云需求，可否结合蘑菇街上云的经历为大家分享遇到的坑和积累的经验教训呢？

[size=100%]赵成：简单讲只有四个字：胆大心细。为什么会这么讲呢？

[size=100%]我认为问题和坑总会有的。因为虽然云服务肯定是趋于标准和通用的，但是我们每个公司的业务都是非常个性化的。所以，本质上我们遇到的问题都是通用和个性之间的差异造成的。这种情况靠任何一方单方的力量都不会有太大效果，必然需要双方共同配合，一起改进和适配。

[size=100%]所以重要的经验就是跟云厂商做好充分合作，并给予云厂商充分的信任。我觉得现在业界有一个非常不好态度，那就是总说云厂商不靠谱、不稳定。其实达到靠谱稳定这个目标是需要有个过程的，是需要多一些耐心和容忍度的。

[size=100%]谈到具体到实施层面，首要问题是解决数据迁移的问题，包括关系数据库、大数据以及其它各类NoSQL存储。因为数据是有状态的，所以这里的难点是如何做好数据同步，以及确保最终数据一致性的问题，当时我们也为此开发了很多自动化的校验工作来做保证。

[size=100%]其次就是解决中间件这一层的部署，这里主要是指各类服务发现和选主的策略设定以及隔离。

[size=100%]最后是应用层的部署。如果这方面的架构设计的好，系统应该都是无状态的。所以从复杂度上相对简单，只是需要投入更多的部署和测试。

[size=100%]通过这整个过程的介绍，你会发现，工具的完善程度、架构的合理性、应用开发的规范等都会直接影响到迁移的效率和稳定，所以应该把更多的工作放到做到平时来做。

[size=100%]TOP100组委会：第七届TOP100全球软件案例研究峰会即将来临，赵老师将会给大家带来什么干货呢？可否提前透露些精彩预告?

[size=100%]赵成：我会分享一下我们在SRE方面的一些实践。虽然每家公司都在做一些同样的事情，但是SRE给我们提供了一个很好的思路和指导思想，让我们做的事情能更加充分地发挥价值。前面已经剧透了很多，这里就不再详细描述了，大家可以关注我的演讲。

[size=100%]赵成，蘑菇街技术总监，资深DevOps和运维专家，专栏作家，著有《进化：运维技术变革与实践探索》一书，腾讯云TVP，现任蘑菇街集团技术总监。

[size=100%]TOP100组委会：赵老师您好，非常荣幸能采访到您！赵老师是运维专家又是资深DevOps，是什么让您从传统运维走向DevOps？可否为大家介绍一下您的从业经历？

[size=100%]赵成：专家和资深，更多是外部对我的称呼。我觉得最重要的是一个人在职场上是否可以脚踏实地的解决实际问题，帮助公司成长。回到问题上，我认为传统运维和DevOps之间并没有什么严格的界限。这个转变更多的还是跟随软件架构的演进，一步步发展过来的，或者准确的说，软件架构发展的同时，也给运维带来了更多的发展空间。

[size=100%]我早期在华为负责的电信软件产品更多的是单体或分层架构，少部分是服务化架构。这些软件迭代周期比较长，并且遵循严格的IPD研发流程，因此，上线后的软件质量一般都相对可靠。所以在这种情况下，一线运维的同事关注的焦点更多的是在硬件和系统层面，只需要将系统层面的事情运维好即可。

[size=100%]但是随着互联网行业的高速发展，服务化、分布式、微服务这样的软件架构被广泛采用，运维所面临的问题就变得完全不一样了，软件模块，也就是我们常说的应用数量突然变多，变化频繁（每天发布），所以作为运维，要关注的焦点自然会偏移到应用层面。这种新的场景必须要有新的解决方案去应对，于是DevOps、SRE等优秀的理念和实践也就诞生了。而传统运维和DevOps之间的转变就顺其自然地发生了。

[size=100%]所以，总结下来就是我的第一句话所表达的意思：不管是做开发，还是做运维，需要时刻拥抱变化，脚踏实地解决每一个问题。

[size=100%]TOP100组委会：综合您的从业经历 ，能否简单为我们讲述下您认为传统运维和DevOps运维的主要的异同点在哪里？可否结合您在蘑菇街的实战经历为大家做相关介绍？

[size=100%]赵成：传统运维更加关注物理设备层面的维护，但是DevOps会更加强调应用层面的运维。或者准确说，是需要具备从应用的视角去做运维的思路。

[size=100%]由于软件架构的演进以及云计算行业的飞速发展，底层的基础设施被做的越来越完善。你会发现越底层的东西变得越来越标准化，比如阿里云的ECS和AWS的EC2，从使用的角度来说，其实差别并不大。这就给传统运维带来了很大的挑战，除了上面第一个问题中提到的场景挑战，还有两个主要的挑战：一个是发展空间受限；另一个是岗位需求量在趋于萎缩。所以，在思路上做转变在职责上转型就很必要了，或者更准确的说是面对新的场景，不得不转，这是个倒逼的过程。

[size=100%]从蘑菇街的经验来看，我们当时转型的时候，一方面从大厂招聘有经验的应用运维比如从阿里等，来作为经验的输入；另一方面不断向外部学习，看别人是怎么做的。最后就是我们自己去摸索实践。当时我们内部制定了一个原则：一定要站在开发和业务的角度解决实际问题。从实际问题出发的好处之一就是不会被各种理念、概念和技术搞的云里雾里，也不会不知从何入手。所有的技术应用都是为了解决问题。依靠这个原则去做事情也会更脚踏实地一些。

[size=100%]在转变的过程中，前期会痛苦些，因为根本找不着北。但是一旦摸到了方向，并坚持做下去就会越来越有感觉，越来越知道自己应该做什么。方向对了，路再远也不怕。

[size=100%]TOP100组委会：在蘑菇街运维成功转型后，稳定性依然是考验运维部门运维状况的一个重要指标。为了达到这个目标，团队需要未雨绸缪做哪些准备呢？

[size=100%]赵成：简单来讲，要从意识入手、形成标准、再到文化建设。这是一个体系性的工程。

[size=100%]之所以从意识入手，其原因是在一开始甚至是稳定性建设过程中，我们的工具和体系有时候还不够完善。此时我们很难直接依赖技术手段来保证系统稳定，很多变更操作也没法一下子全部通过自动化的工具完成。

[size=100%]在这个阶段，为了避免一些重大、低级、人为的失误，就需要在意识上进行加强。最简单有效的方式就是制定高压线。制定高压线就是规划好底线，触碰底线就要受到处罚。比如白天不允许操作网络设备，不允许做大表变更、不允许做拔插网线等操作。虽然看上去好像不是那么高大上，但是往往最有效，可以避免很多低级失误造成的严重故障。

[size=100%]其次是高压线一旦制定出来，就要把它变成一种习惯。当每个人对线上的敬畏心理形成后，高压线的震慑力就显现出来了。别说高压线不敢碰，就是一般的电线和电源在处理之前，都需要掂量下这种操作是不是有危险。所以，在很多流程规范约束不到的地方，这种方式就可以起到很好的补充作用。

[size=100%]2015年我到蘑菇街的时候，有一段时间故障频发。虽然我们制定了各种很细节的流程规范，但这些规范的效果并不好。后来就制定了高压线，简单易记，并且约定一旦违反就要受到处罚。通过此种方法，我们基本可以避免较大的故障。其实这其中的关键是人一旦形成意识并主动思考，就会主动规避风险。而如果是被动执行，那么有时候往往就不会考虑这么全面。

[size=100%]这个话题比较大，关于标准和文化部分，我先不展开讲了，这是我12月份演讲的主要内容，大家可以关注我的演讲。

[size=100%]TOP100组委会：Google SRE的理念如今大行其道，请问这套理念的核心关注点是什么？和国内运维团队的运维理念有何异同？

[size=100%]赵成：首先SRE(Site Reliability Engineering)是指站点可靠性工程师，最初由Google提出并实施推广。SRE的主要职责是保证站点的可用性，因为他需要对站点系统、组件节点、服务调用等较为熟悉，并需要关注生产的服务状况。在Google SRE中还提出了SLI，SLO，SLA的机制。我认为以下几点是这套理念的核心关注点：

[size=100%]1.SLO稳定性标准。根据系统运行的实际情况来设定合理的指标范围。SRE设定了SLO之后，无论开发、运维还是管理者都必须遵照这套标准处理问题。

[size=100%]2.50%原则。这一点主要强调SRE并不能被琐事缠身。无论他多忙，都要有50%的时间用来开发工具，从而解决重复的琐事。从另外一个角度，这也说明SRE更加强调技术解决问题，而不是靠管理以及流程之类来保证系统稳定性。

[size=100%]3.事后总结。Google非常重视从故障案例中总结提取经验，从而找到改进措施。我之前也提到过：故障永远是表象，背后的技术和管理问题才是本质。当这些问题积累到一定程度就会爆发出来。因此，故障最能够体现一个团队的技术和管理能力，也能暴露现存的问题。所以我们可以从中了解到：案例学习是一种非常简单且有效的提升手段。

[size=100%]4.No Blame文化。这一点主要是指就事论事，永远不要指责、抱怨团队和队友。只有在这样的环境下，大家才能敞开心扉，并且真正站在如何改进的角度去考虑问题、去解决问题，而不是担心自己被指责、被处罚。

[size=100%]这四个点，也将是我在这次大会演讲中分享的观点，欢迎大家关注。

[size=100%]TOP100组委会：听闻蘑菇街业务已开始全面上云。为什么蘑菇街要由原来的技术自主可控转变为与公有云厂商共同合作，走上全面上云之路呢？

[size=100%]赵成：我们依赖的是公有云厂商的基础设施和基础服务发展。这里主要有两个原因：

[size=100%]第一个是基础设施和服务越来越趋于标准化。无论是虚拟机、网络、数据库，还是软件层面的分布式缓存、对象存储、消息等，这些都已经非常标准通用了。这些产品在大的云厂商公有云服务上都有很长时间的运行和使用，所以既然已经有现成的服务了，为什么自己还要再重复造轮子呢?

[size=100%]第二个点是基础设施和分布式服务的搭建和运维较为复杂。技术难度和复杂度曲线在大规模应用的场景下会变的异常陡峻。因此需要有持续的、规模性的专家人力投入。对于一般企业来说，这项投入消耗太大，靠自己力量去投入实施不太现实。而且即使自己做，也不见得比业界厂商做的好。所以从这个角度出发，我们就更没有必要自己去做了。

[size=100%]我们会将更多的精力专注在业务技术发展上，让技术更多地为业务创造价值。

[size=100%]TOP100组委会：蘑菇街整体业务上云一定经历了很多事情，现在许多公司也有上云需求，可否结合蘑菇街上云的经历为大家分享遇到的坑和积累的经验教训呢？

[size=100%]赵成：简单讲只有四个字：胆大心细。为什么会这么讲呢？

[size=100%]我认为问题和坑总会有的。因为虽然云服务肯定是趋于标准和通用的，但是我们每个公司的业务都是非常个性化的。所以，本质上我们遇到的问题都是通用和个性之间的差异造成的。这种情况靠任何一方单方的力量都不会有太大效果，必然需要双方共同配合，一起改进和适配。

[size=100%]所以重要的经验就是跟云厂商做好充分合作，并给予云厂商充分的信任。我觉得现在业界有一个非常不好态度，那就是总说云厂商不靠谱、不稳定。其实达到靠谱稳定这个目标是需要有个过程的，是需要多一些耐心和容忍度的。

[size=100%]谈到具体到实施层面，首要问题是解决数据迁移的问题，包括关系数据库、大数据以及其它各类NoSQL存储。因为数据是有状态的，所以这里的难点是如何做好数据同步，以及确保最终数据一致性的问题，当时我们也为此开发了很多自动化的校验工作来做保证。

[size=100%]其次就是解决中间件这一层的部署，这里主要是指各类服务发现和选主的策略设定以及隔离。

[size=100%]最后是应用层的部署。如果这方面的架构设计的好，系统应该都是无状态的。所以从复杂度上相对简单，只是需要投入更多的部署和测试。

[size=100%]通过这整个过程的介绍，你会发现，工具的完善程度、架构的合理性、应用开发的规范等都会直接影响到迁移的效率和稳定，所以应该把更多的工作放到做到平时来做。

[size=100%]TOP100组委会：第七届TOP100全球软件案例研究峰会即将来临，赵老师将会给大家带来什么干货呢？可否提前透露些精彩预告?

[size=100%]赵成：我会分享一下我们在SRE方面的一些实践。虽然每家公司都在做一些同样的事情，但是SRE给我们提供了一个很好的思路和指导思想，让我们做的事情能更加充分地发挥价值。前面已经剧透了很多，这里就不再详细描述了，大家可以关注我的演讲。