《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的工作越好，那么在公司其他团队里就越不容易被感知。因为很多工作，要尽可能接近自动化实现。
当然，比较戏剧的是，透明反而被人容易误认为是「闲」，遭遇被「过河拆桥」的厄运。
特别是在国内「儒」家作为主要的管理之道，相对并不太尊重工程师文化而言。毕竟从「罢黜百家独尊儒术」的那一天开始，「匠人」的社会地位就开始大大衰落。这时候又忍不住要感慨下老墨子的「任人唯贤，量才而用」的博大精深了。
这也是作者一直在思考的问题，目前鄙人的观点是：跟对人很重要，慎重选择团队。但我觉得运气也是重要的组成部分，毕竟人心总是善变，也欢迎纠错指正。
「天时地利人和」「努力、天分和运气」都缺一不可。
对于个体而言，得之吾命，失之吾幸，凡事随缘，尽力就好。
也祝愿每一位技术从业者，无论身上背着怎样的重担，处境如何。每天都能开开心心的能吃能睡能写代码。
「愿你归来时，仍是少年。」
