自序
你好,我是赵成,来自美丽联合集团,集团旗下两大主力产品是蘑菇街 和美丽说,我目前负责管理集团的技术服务团队。
本书的内容主要来自我在极客时间的专栏《赵成的运维体系管理课》。
当我写完专栏时,我的专栏编辑李佳告诉我文章可以集结成书出版,这 时我才意识到,原来我在写作专栏文章的过程中,已经不知不觉地将一个相 对比较完整的运维体系输出了,当时的感觉:一切都是水到渠成的。
所以,这里首先要感谢极客时间这样一个优秀的、为技术人服务的知识 内容平台,我不但从极客时间中学到了很多知识,而且对于我个人而言,它 也是一个舞台,能够让我将个人的实践、经验和总结通过最有价值、最有效 的传播方式呈现出来。如果没有这样一个舞台,本书中的内容可能还要延期 很长时间才能面世。
与极客时间结缘,是在 2017 年的 QCon 上海大会前夕,我接到了极客 时间团队的邀请,问我是否可以做一个运维专栏,我当时的第一反应是有些 兴奋,这还真是一个意外的邀请。但是接来下我的反应就是诚惶诚恐,因为 我自己写公众号也有一段时间了,深知持续高质量输出这件事情的挑战之大, 特别是在输出专业文章上更是如此,所以当时一直拿不定主意。
我写公众号文章,在很大程度上是因为之前有过很多次公开演讲和分享的经历,后来发现演讲所面向的受众和时间有限,分享的内容无论是在传播的广度还是内容的深度上,都会受到很大的限制。总之,讲得不过瘾,索性就把一些我觉得还值得更深入探讨的话题和内容完完整整地写出来。
后来,在上海跟极客时间团队见面之后,他们给了我一些建议,因为之前的文章更多是针对一个个观点延伸出去写作,而专栏文章可以尝试更系统地输出,能够把一个运维体系讲透彻。这个建议从一定程度上打开了我写专栏的思路,后来我把内容规划了一下,感觉还是可以输出一些更有价值的内容的,因此就启动了这个专栏的策划。
再后来,就有了本书的全部内容。
这里要特别感谢在我写作专栏和出版图书的过程中帮助和支持过我的人。
感谢我专栏中的读者,你们的信任和反馈是对我最大的支持,也是对我最大的督促,没有你们,就不会有本书高质量的内容输出。
感谢我的专栏编辑李佳,从专栏策划之初就协助我做了大量的内容策划、制作、校订以及各种协调的工作,直至图书出版;感谢极客时间团队,正是因为有了你们,才有了如此优秀的产品。
感谢我的图书编辑侠少和恩惠,帮我进行图书内容的策划和制作,我们相识已久,这次终于有机会合作。
感谢蘑菇街,正是基于这样一个非常优秀的平台,我才得以有机会不断地实践和尝试,也感谢我团队所有的小伙伴,本书所呈现的成果是我们共同努力和实践的结果。
最后,感谢我的妻子朱悦和我的家人,无论在工作还是生活中,你们给予了我最无私的支持。我把本来应该陪伴你们的时间用来写作,感谢你们的理解和奉献。
一路走来,有你们相伴,就是最幸福和开心的事情。
赵成
2018年4月13日于杭州
前言
谈谈运维的价值
我们在大学的软件工程课程中学过,从软件生命周期的角度看,软件开 发阶段只占整个生命周期的 20%~30%,软件运行维护阶段是最长尾的,这 条规律放在当前这个时代同样适用。
Bob 大叔,Robert C.Martin,在其最新图书 Clean Architecture(中文版 由电子工业出版社出版)中对软件架构的目的给出了他的理解:
软件架构的目的,是将构建和维护所需的人力资源降到最低。
一语中的,直击本质。本书的全部内容基本都是围绕着这句话展开的, 我想正对应了万变不离其宗这条规律。
在软件生命周期中,我们可以很清晰地划分出“开发阶段”和“运维阶 段”,这个分界点就从开发人员完成代码开发,测试人员验收通过后,交付 到运维人员手上的软件包开始,自此之后的阶段就是软件的运行维护阶段了。
一家公司对于开发的诉求应该是全力实现业务需求,并将需求尽快发布 上线以实现商业上的收益。但是,在一家公司里,除了专注于业务需求的开 发和测试角色,还会有另外一大类开发,比如我们常见的中间件开发、稳定 性开发、工具开发、监控开发、IaaS或PaaS平台开发,甚至专注于底层基础架构的内核开发、网络开发、协议开发等。
如果仔细思考,我们会发现除了业务开发和测试,前面所提到的那些技术岗位都是为软件生命周期中的运行维护阶段服务的,这些角色的作用就是提升研发效率和稳定性,进而降低成本。虽然它们并没有全部被定义为运维岗位,但是本质上它们是跟业务软件的运行维护阶段直接相关的。
所以,从运维的范畴来讲,我认为,在一个研发团队内,除去业务需求实现层面的事情,其他都是运维的范畴,实质是软件架构的范畴,它们都在为软件生命周期中的运行维护阶段服务。
我之前在外部分享中一直表达的一个观点就是,运维能力是整体技术架构能力的体现,运维层面爆发的问题或故障一定是因为整体技术架构中存在问题,割裂两者,单纯地看技术架构或运维都是毫无意义的。
但是,我们在绝大多数情况下都忽略了这个隐藏在软件生命周期中真正的运维范畴,而是简单直接地从软件生命周期分段的角度,生硬地给开发和运维划定了一条界线。
我认为,跳出运维看运维,从架构角度看运维,这种运维思路上的转变,远比单纯提升运维技术更有价值。
而这也正是我们很多公司和团队当前存在的最大的痛点和问题。所以,在本书中,我会针对这些痛点和问题分享一些我的思考。
图书内容结构
本书的内容会聚焦在分布式软件架构下的应用运维这个领域,更多的是我对运维的一些架构思考,主要可以分为以下四个部分。
(1)应用运维体系建设,包括第1章~第4章的内容。这是我们做运维的基础,我会首先分享运维的本质是什么,明确运维的核心概念,并从标准化和应用生命周期开始,讲述如何一步步建立运维技术体系和组织架构,整个过程中的沟通协作以及我们应该如何树立正确的运维建设思路等方面的内容。
(2)效率和稳定性等方面的最佳实践,包括第5章~第7章的内容。这些是运维价值的体现,我会围绕持续交付、稳定性建设以及故障管理三个方面,分享如何打造不需要任何运维参与的端到端交付过程,如何在实践中锤炼出稳定性保障体系,以及如何看待故障并做好故障管理。
(3)云计算方面的思考和实践,包括第8章和第9章的内容。云计算技术的蓬勃发展为我们的业务和技术提供了更多的可能性,利用好云这个平台将会是运维升级转型的必备要求。我会分享在混合云、云存储、静态化以及CDN上的实践经验,以及这些实践给成本和体验带来的巨大收益。
(4)个人成长与趋势热点分析,在第10章进行分享。这一部分更多的会是我个人的一些思考,包括运维技术发展趋势、团队管理、个人成长、热门事件解析、观点碰撞等。
另外,由于运维和安全之间有着密不可分、唇亡齿寒的关系,在工作中也有较多的交集,因此,我将“运维与安全”作为拓展阅读放于本书的最后,希望能引发大家更多的思考。
最后,开卷有益,期望本书能够带给你不一样的运维思考,共同进步。
黄云斌 2018-06-18
这本书是说运维的,看完却发现几乎没有任何运维细节,我觉得说的完全是架构的事情。运维要的是标准化,服务化,标准化的步骤是抽象出对象,对象属性,对象关系,对象场景,架构同理。运维的目标是稳定性,效率,减少成本,架构同理。保证稳定性,如果容灾,都是架构考虑的重点。很佩服的是作者通篇的思路观点都非常清晰,甚至把人员的离职类比技术的容灾,管理的技术化思维啊。文中强调一句话让我感触颇深:理解系统如何工作并不会... 这本书是说运维的,看完却发现几乎没有任何运维细节,我觉得说的完全是架构的事情。运维要的是标准化,服务化,标准化的步骤是抽象出对象,对象属性,对象关系,对象场景,架构同理。运维的目标是稳定性,效率,减少成本,架构同理。保证稳定性,如果容灾,都是架构考虑的重点。很佩服的是作者通篇的思路观点都非常清晰,甚至把人员的离职类比技术的容灾,管理的技术化思维啊。文中强调一句话让我感触颇深:理解系统如何工作并不会让你成为专家,调查系统为何不能正常工作才能。面向问题编程和架构或许是短期的工作重点,不断发现提出问题,解决问题。以应用为起点,找到价值点也是要考虑的地方。当然该书的第五章我是觉得写得不怎么样。 (展开)