谈谈运维稳定性_关于平台稳定性运维(1)

3. 事后，还需要组织进行深度复盘和根因分析(Postmortem/Root Cause Analysis)。我们需要做到从失败中学习，并尽量保证未来不会掉进同样的坑。

4. 前三步都是在做一些防御工事，我们应该尽量在测试阶段就发现问题，并通过科学的发布过程来保证不会轻易引入新的线上问题(Testing+Release procedures)。

5. SRE们还需要关注容量需求的变化情况(Capacity Planning)。系统是动态的，我们需要尽力做到让资源在适当的时机，能够灵活的调配到真正需要他的地方。

6. 以上做好之后，还需要关注一些研发的工作(Development)。这部分包括原先的系统实现是否合理，从问题反推，是否可以有更合理的设计，并推动优化。当然还有一些必要的工具也需要开发。

7. 稳定性最终极要关注的是产品本身(Product)。从用户角度，稳定性意味着什么？哪些是他们核心关注的？我们应该努力通过产品和流程设计等减少用户对系统故障的感知，甚至做到无感。

有了上面介绍，从运维的角度去分析，是需要把上面金三角的地基打好。

就是基础监控以及故障响应、复盘文档做好。

而基础监控因公司架构而异：

有的公司是全云架构，这种监控做起来会比较轻松，因为部分base监控可以使用云自带的，一些中间件再自己使用开源的即可，例如普罗+grafana即可，再加上各种export收集中间件的数据。

而如果有自己idc机房，有大量物理机器和交换机设备需要监控的时候，需要考虑的指标就多起来了，例如硬件设备的老化、线的老化、网卡的老化等等，每一项的替换都是成本的支出，而往往企业都是对成本看得很紧，这下就见仁见智了。

在降本的情况下，在维持稳定性上面，故障响应以及自动治愈，这就显得十分重要了。

存在很多历史问题无法解决时，如果你的服务上无法做到自动治愈，需要人工手动恢复，故障时长将无法得到保证。分分钟面临的都是客户的投诉。影响面会非常广，大到公司在前面销售的同事没有信心去售卖自家公司的产品等。

复盘故障：每一次可以复盘故障的机会都难能可贵，都是技术的一次积累，防止重复跳坑。

应用发布：devops基本每家公司都在做，一个好的发布平台是可以减少很多业务故障的。因为每一次发布都需要经过一层层的review才可以发布，可以很好降低一些不必要的人工干扰的bug。

最后是业务接口的监控：

延迟（Latency），流量（Traffic），错误（Errors）和饱和度/负载（Saturation）

总结：

1.稳定性的维护是需要大量的耐心。

2.稳定性的维护是维护者在做兜底保底线的事情，很少得到关注，被关注的时候就是出事了。

最全的Linux教程，Linux从入门到精通

======================

1. linux从入门到精通(第2版)

2. Linux系统移植

3. Linux驱动开发入门与实战

4. LINUX 系统移植 第2版

5. Linux开源网络全栈详解 从DPDK到OpenFlow

第一份《Linux从入门到精通》466页

====================

内容简介

====

本书是获得了很多读者好评的Linux经典畅销书**《Linux从入门到精通》的第2版**。本书第1版出版后曾经多次印刷，并被51CTO读书频道评为“最受读者喜爱的原创IT技术图书奖”。本书第﹖版以最新的Ubuntu 12.04为版本，循序渐进地向读者介绍了Linux 的基础应用、系统管理、网络应用、娱乐和办公、程序开发、服务器配置、系统安全等。本书附带1张光盘，内容为本书配套多媒体教学视频。另外,本书还为读者提供了大量的Linux学习资料和Ubuntu安装镜像文件，供读者免费下载。

本书适合广大Linux初中级用户、开源软件爱好者和大专院校的学生阅读，同时也非常适合准备从事Linux平台开发的各类人员。

需要《Linux入门到精通》、《linux系统移植》、《Linux驱动开发入门实战》、《Linux开源网络全栈》电子书籍及教程的工程师朋友们劳烦您转发+评论

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以点击这里获取！

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！