《DevOPS》- 序章
sagescaling.com
本书通过使用当下符合云时代理念的技术栈, 从零起步,一直指引到大家(渴望提升运维开发技能的人)能搭建出功能完善、真实可用的企业运维管理平台。包括但不限于:
1. 资源和服务的自动初始化
2. 发布系统,自动发布与灰度发布等实现
3. 监控平台,报警与日志的搜集处理,指标创建
4. 微服务体系,链路跟踪等解决方案实现
同时也对未来流行的技术概念,如「FaaS」等,提出可能的实现方案。
在实战中,理解理论知识,学习DevOPS技术栈。
Part 1 写在最前
-本书籍适用人群
运维人员,对运维技术感兴趣的开发者。
-为什么写这本书?
写一本技术类书籍,一直是我遗愿清单中的必选项,现在是时候来完成了!(手动滑稽)
-阅读门槛
作者认为完成本书的阅读和实战入门门槛不是很高,前期只需要具备:
1. 理解Linux基础操作,熟悉常用的 shell 指令
2. 具备基础的编程的基础知识,理解什么是API等基础概念
3. 理解常见的云设备的概念,云主机、云交换机等
Part 2 有关于
在本书中如果遇到不懂的专业名词,而作者又未能详尽解释的,建议自行搜索理解后再继续阅读。
每一章分为理论和实战两部分,理论部分尽量丢掉晦涩的专业术语的表达方式, 毕竟纯讲专业知识,「面向搜索引擎学习」就解决了,这也是作者很讨厌的学习方式之一。
在每一章,我会列出「依赖知识储备」。读者可以自行根据条件,补充前置知识。同时为了方便有些运维经验的人阅读,每一章节,添加了难度系数值, 方便不同经验的根据需要跳过某些章节:
1. ⭐️ 初级难度,有丰富运维经验的读者可跳过
2. ⭐⭐️ 中级难度,初学者建议跟随文章逻辑进行实战,经验丰富的读者可直接下载demo运行
3. ⭐⭐⭐️ 高级难度,概念较多,建议紧跟文章逻辑进行实战
Part 3 我是谁
目前就职于某创业公司的SRE一枚,负责公司整个运维体系的架构及实现,在哪里不重要,喜欢这本书就好。
SRE的全称是:Senior Rebooting Engineer (资深重启工程师), 开个玩笑,嘿嘿,其实这是行业黑话。不过在自黑戏谑中也道尽了SRE的终极状态:「如果真有问题,那就重启吧。其他的事情我们也搞不定了😂,毕竟该做的前期都做了,能查的也都查了。」
所以平常请对你的服务器好一点,钱多没地方花也可以去拜拜机房啥的(律师函警告⚠️请自行搜索:运维拜机房经典图片)
SRE的真实全称是:Site Reliability Engineer。严格意义上最早这个「理论」 & 「岗位」是由Google提出的。有兴趣的同学可以去Google的招聘页自行了解。
对于SRE理论Site Reliability Engineering ,Wikipedia解释的也比较全面。
相信有很多读者看到这么冷的Wikipedia的内容瞬间产生惧意,别慌,给你看个作者的俗人版:
简单说其实SRE的艺术就是「通过创建工具,来完成运维的工作」,「能用机器做的事,就不要用人来完成」。
「write once,run anywhere」可以说是SRE的毕生追求,也是衡量SRE开发成果好坏的指标。
早年国内的「运维开发工程师」、「DevOPS工程师」在作者看来其实都是一个意思, 只不过这套方法论,被Google最早的总结出来。
Part 4 DevOPS
DevOPS也是当今技术界热度很高的话题之一,而作者认为,这个话题也势必成为会持续探讨下去。
在作者看来:「追求个人生产力的持续提高」是每个软件工程师的毕生追求, 所以只要「软件工程」的运行交付模式不改变,DevOPS的技术栈将一直进化一直迭代。
关于DevOPS的观点有很多,到现在也可以认为是众说纷纭,如果你以「什么是DevOPS」来搜索, 你能得到相当多的答案。
但无论哪一种,有一种是「绝对」错误的,那就是:把Dev(开发者)的工作量和OPS(运维人员)的工作量简单 相加,即认为是DevOPS。我要特别说明:
Dev+OPS ≠ DevOPS
这也是很多初创公司在犯的错误,这种模式,最多只能叫做「Full Stack Engineer」。
提到DevOPS,就必须要提著名的DevOPS无限迭代图
其实这张图也说的很明白,DevOPS技术栈其实专注的是整个链条的运转,如何让链条环节更快、更稳定。这才是DevOPS的真正价值。
在这里,跟大家分享一下,也是我认为读者日后参与相关工作时,需要永远铭记三条非常重要的视角:
●Infrastructure as Code(基础设施即代码)
在后续章节,我会向你展示如何实现IaC
●Container as a Service(容器即服务)
在后续章节,我会向你展示如何实现CaaS
●人类不可靠,人类很容易犯错
Part 5 做好运维工作的秘诀
运维工作其实对很多开发者是一件头疼的事, 很多萌新程序员都是从看不起运维工作到最后被虐到体无完肤。
「初生牛犊不怕虎,虐完已是成年人」😂😂😂
如果你只是想简单的完成运维工作,任何一个开发者完成自己项目的部署工作,都可以认为完成了运维工作。
但是把运维工作做好是另外一件事情了,随便罗列几点:
1. 如何在几分钟之内快速的发布已经开发好的功能?
2. 能不能自动发布开发好的功能?
3. 在项目中如何实现灰度发布?
4. 如果服务有问题,我们怎么样快速回滚代码?
5. 如何避免服务器出现安全漏洞?
6. 线上服务有异常我们要如何监控?
7. 报警数量太多容易麻木,太少容易漏报,如何规划合理的报警项?
8. 如何评估我们团队的各项服务的质量好坏?
9. 如何应对突如其来的流量激增?
10. … …
怎么样?是不是感觉到了运维工作的压力。别担心,只要跟随本书的章节, 你会慢慢学习和理解如何更好的完成运维工作。希望读者能铭记以下两条定律:
1.墨菲定律。
只要时间够久,之前忽略的问题迟早会发生,对于运维工作而言,墨菲定律就像是魔咒一样, 只要是线上发现的隐患,总有一天迟早会发生,这是必然的。
2.奥卡姆剃刀定律。
如无必要,勿增实体。
运维技术栈一直在持续迭代,有相当多的运维风险,都是没有经过充分验证, 贸然引入了新的技术栈带来的。
运维工作其实就像盖房子,技术的革新总有办法盖出越来越高的楼。我们不能因为技术实现可以盖到100层的楼,就要盖到100层,而要根据实际的需求定制。四口之家盖个小别墅,住起来多舒服,最重要的是「实用 & 美观」。赏心悦目是人类的高级需求之一,两者缺一不可。万丈高楼是美,别致园林也是美。
运维工作也是如此,一个10人规模团队就不要引入1000人才能驾驭好的技术栈。一个10万流量的项目,不要去过早引入流量过亿的技术架构。
没有最好的架构,只有最合理的架构,合适的才是最好的, 好的架构是演进出来的,保持前瞻性,持续迭代。
怎么判断前瞻性?分享一个简单的判定指标,在任何一个阶段,对当前团队来说具备良好的可维护性,就可以认为是良好的架构。
Part 6 实战环境依赖
●Debian Linux/macOS 操作系统
●Terraform v0.12.5
●Ansible v2.5+
●Git
●Github账号
●Python3.5+ (可选)
●已注册相关云平台账号
●正常的网络环境可正常访问
https://releases.hashicorp.com
●更多依赖软件请留意各章节的前置依赖
Part.7 风险提示与免责声明
由于本书是从零开始搭建,而运维工作本身是严谨 & 容易造成损失的。为了简化教学难度,有些章节牺牲了安全性降低了操作难度。所以:
请读者不要在生产环境中操作演示代码!请读者不要在生产环境中操作演示代码!请读者不要在生产环境中操作演示代码!
重要的事情说三遍,由于使用本书demo产生的任何线上漏洞和损失,本人不承担任何责任。
如果不同意,请放弃阅读。继续阅读本书将表示读者已经同意作者的风险提示,产生的任何风险由读者自理。
Part 8 你将收获
工具链:
●理解并熟练使用 Ansible
●理解并熟练使用 Terraform
●理解并熟练使用 Docker
●理解并熟练使用 Kubernetes
●理解并熟练使用 CI/CD
●理解并熟练使用 监控技术栈
其实工具不是主要学习目的,学习工具的使用太容易了, 对于SRE而言,重要的是解决问题的思路和方法。
而工具本身也一直在迭代进化,唯有分析问题的方法不变。子曾经曰:「君子不器」,也是这个道理。不要拘泥于工具中, 而是要先有解决方案,再找顺手的工具的来解决问题。
在运维技术栈中,很多萌新容易进入一个误区:过度依赖工具,而不细究工具的原理。工具是为人服务的,而不要成为工具的奴隶。技术栈不是流行什么就用什么,而是要选择适合当前业务的技术栈。
「合适的才是最好的」
所以本书除了讲解当下流行的技术栈之外,也会侧重在运维策略上进行分享:
●掌握云时代运维的思路和方法
●如何系统化快速定位线上问题
●学习运维团队的管理哲学
●如何为业务产品构建运维指标
●学习如何评估运维成员工作的质量
Part 9 优秀SRE的指标
1.会真正「偷懒」
一名优秀的SRE应该能通过总结问题,汇总出工具箱,强化个人和团队的生产力。在大多数人理解中,可能要几天完成的工作量,你只用几个小时甚至几分钟,当然优秀。
2.像空气一样透明
SRE的工作越好,那么在公司其他团队里就越不容易被感知。因为很多工作,要尽可能接近自动化实现。
当然,比较戏剧的是,透明反而被人容易误认为是「闲」,遭遇被「过河拆桥」的厄运。
特别是在国内「儒」家作为主要的管理之道,相对并不太尊重工程师文化而言。毕竟从「罢黜百家独尊儒术」的那一天开始,「匠人」的社会地位就开始大大衰落。这时候又忍不住要感慨下老墨子的「任人唯贤,量才而用」的博大精深了。
这也是作者一直在思考的问题,目前鄙人的观点是:跟对人很重要,慎重选择团队。但我觉得运气也是重要的组成部分,毕竟人心总是善变,也欢迎纠错指正。
「天时地利人和」「努力、天分和运气」都缺一不可。
对于个体而言,得之吾命,失之吾幸,凡事随缘,尽力就好。
也祝愿每一位技术从业者,无论身上背着怎样的重担,处境如何。每天都能开开心心的能吃能睡能写代码。
「愿你归来时,仍是少年。」