解读《运维知识体系》，直面自动化运维的“灵魂八问”

赵班长带领大家详细学习运维知识体系，介绍了缓存知识体系，抛出检测公司自动化运维承受度的“灵魂八问”，最后跟大家分享了运维的趋势和挑战。

想看精彩直播回放，请点击这里。

以下是精彩直播内容整理：

运维知识体系赵班长从2015年开始写，一直到现在，整个体系是按照HTTP的请求流程，从浏览器发出请求到最后收到响应，所经历的所有技术栈。

运维知识体系可以做什么？

第一，如果你想成为运维架构师，那么你需要掌握运维体系中所有内容；

第二，可以帮助运维朋友划清运维的边界，因为整个运维体系非常大，未来到底朝哪个方向发展？可以根据运维知识体系给自己画一个圈。

运维知识体系

从整体上看，运维知识体系是按照客户端层、外部层、网络层、接入层、应用服务层、存储层、基础服务层、容器层、操作系统层、基础设施层等结构编写，也是作者十年运维工作的总结。

客户端层

对于客户端层中的浏览器层，作为运维要掌握非常多的知识，比如浏览器的缓存协商，其中包括三种不同的缓存协商办法；浏览器还涉及到很多前端相关工作，比如cookie作用域，如何通过使用不同顶级域名来减少静态资源cookie的提交，以及前端性能的优化，比如如何实现Css和js请求合并，把多个请求合并成一个请求，还包括组件分离，如何针对静态资源来做不同的组件分离；浏览器还涉及到运维相关的一些工具，比如出现故障，给用户发送一个页面，通过页面可以做一些正常的路由检测、PING检测和DNS检测，也需要我们掌握HTTP协议相关东西。

浏览器层再往下就是DNS层。DNS需要掌握DNS缓存，比如浏览器DNS缓存，火狐或谷歌浏览器默认是60秒DNS缓存，还涉及到DNS服务器的DNS缓存，以及DNS缓存服务器；DNS还需掌握DNS知识，包括DNS基础知识，比如如何进行递归和迭代的查询，如何自建DNS，以及如何使用公共DNS，如图即是阿里公共DNS，公共DNS都需要什么样的技术等等。

DNS层之后就是客户端/APP层，浏览器是客户端，还有其它C/S结构的客户端及手机APP也作为客户端，在客户端层涉及到客户端的请求与访问，比如HTTP-DNS，即通过HTTP协议进行域名解析，可以解决local DNS不准确或者调度不准确和缓存等问题，客户端/APP还涉及到怎么去传输协议，以及怎么去做加密传输、打点日志和监控SDK；还有业务领域的一些知识，比如客户端/APP如何做消息推送、直播推流等场景。

外部层

一个请求通过客户端层之后就会到外部层，如外部CDN，之前我所在公司使用了公有云服务，有自己的托管机房，外部CDN就需要掌握CDN技术，包括全局负载均衡、反向代理缓存，包括CDN如何做分布式存储、如何做流量调度、配置管理，作为用户来说，我们还需要掌握CDN各类 API的调用，比如我们经常会集成各家CDN，如带宽监控、预缓存和缓存刷新等。

在外部安全防护层面，我们使用第三方安全解决方案，如阿里云的高防IP（防DDOS、防CC攻击、WAF等）。

网络层

在客户端层、外部层之后，请求就会流入网络层，因为我们有多机房建设，包括公有云、私有云。网络层包括由上到下包括互联层、核心层、汇聚层和接入层：

接入层

请求接入网络后，就流到了接入层，接入层有负载均衡设备，负载均衡又分为四层负载均衡和七层负载均衡，四层负载均衡需要掌握LVS（IP负载均衡）+Keepalived、Haproxy，包括一些商业负载均衡：F5、Netscaler；七层负载均衡需要掌握反向代理：Haproxy、Nginx、Apache（根据HTTP协议支持的属性进行L7分发），还可以实现A/B Test Gateway、WAF等功能。

请求继续向下会涉及到反向代理缓存，包括ATS、Squid、Varnish、Nginx(缓存分级、预缓存、缓存刷新），现在反向代理缓存用的比较少了，因为CDN就是一种反向代理缓存。

应用服务层

请求再往下到达应用服务层，应用服务层最上面是web服务层，作为运维，我们要掌握不同的Web服务器（Apache、Nginx/OpenResty、Tomcat、Resin、Jboss）安全设置、性能优化，我们还要精通HTTP协议；

接着是应用服务层，包括不同软件的运行环境（PHP Python Java C C++）、性能优化、缓存（OPCache、LocalCache）、Session存储、代码部署等；

我在这里还划分了业务层，一个不懂业务的运维一定不是一个好运维，做应用运维必须要了解公司业务，不了解公司的运营模式，怎么能够更好的服务于公司业务呢？业务层又分为业务实现层和服务层。业务实现层我们要知道API网关、302调度、业务模块化（电商例：用户、商品、购物车、结算中心、价格等服务）、微服务等，一个电商可能有几十到上百个微服务模块；服务层需要看每家企业不同的微服务框架（istio、Spring Cloud），比如阿里开源的SOA框架（Dubbo），不同微服务框架使用不同的协议，目前主流使用RPC、RESTful等协议，我们还要关注框架安全、应用性能监控。

再往下到分布式层，主要讲分布式消息队列，做电商时严重依赖于消息队列，比如一些高并发或流量削峰场景都会用到，消息队列包括ActiveMQ（成熟）、RabbitMQ（成熟、案例多）、RocketMQ（业务应用）、Kafka（日志传输）、ZeroMQ（快）等。

存储层

存储层分为文件存储层、DAL层和数据存储层。

存储有三种类型，包括块存储、对象存储和文件存储。在这里我们按照独特的方式对文件存储层进行了划分，比如单机存储，机械硬盘、文件系统和LVM都属于块存储。当单机存储无法满足需求时，就需要单机存储扩展，涉及到文件分发、文件同步、DAS直连式存储等。还有NAS[NFS（Unix/Linux）]、FTP、SAN、iSCSI这类的共享存储，更有GlusterFS、MooseFS、Ceph、FastDFS（非对象存储）等的分布式存储。

文件存储层下面即是DAL数据访问层，越来越多的企业意识到数据访问层的重要性，因为随着数据量的增加，可能需要做数据库的分库分表，这时就需要有数据访问层解决多库多表问题。数据访问层有多种实现，最简单的是应用层分片，直接在应用层做分库分表，还有淘宝自己写的TDDL、开源的360（Atlas）、阿里（Cobar）、MyCat、MySQL-Proxy等。

最后是数据存储层，数据存储层按照很多方式存储：分布式缓存，如Memcached、Redis（客户端分片、Redis Cluster、Twemproxy、Codis）是我们需要掌握的；NoSQL如Redis、LevelDB（SSDB）、CouchDB、Mongodb、Couchbase 、Cassandra、TiDB（支持MySQL协议）；作为运维还要理解时间序列数据库，做监控就特别适合使用时间序列数据库，因为我们采集的所有监控指标就是key、value、时间戳和标签，如RRDTool（还可以做绘图）、Graphite Whisper、OpenTSDB、InfluxDB、KairosDB、ElasticSearch、Hbase；关系型数据库如MySQL（PXC集群、MHA）、Oracle（DG、OGG、RAC）、PostgreSQL、SqlServer、SQLite、DB2；此外，还要涉及大数据的知识，比如Hadoop生态圈（HDFS、Hive、Hbase、Zookeeper、Pig、Spark、Impala、Kudu）、Mahout智能推荐。

到这里，整体架构基本就介绍完毕了，接着我们来看一看跟运维相关的其它层级。

基础服务层

基础服务层又分为以下四点：

容器层

再往下就涉及到系统了，最早是没有容器层的，由于容器技术的火爆，因此本知识体系加入了容器层。

容器层包括容器编排、容器和系统、网络和存储三部分。容器编排有最早的Mesos（Marathon、Chronos）、Kubernetes、Docker Swarm、Rancher、CoreOS（fleet）、OpenStack（Magnum）等；容器和系统也有很多，Docker只是其中一种，还有LXC、LXD、rkt等，系统有CoreOS、Atomic、RancherOS等；容器的网络和存储也是有不同的插件，像网络包括Calico、Flanel、Weave Net等，存储包括Ceph、Docker Registry（镜像管理）、Harbor等。

操作系统层

再往下就涉及到操作系统层，作为运维，我们需要掌握CPU、内存、IO内核。

CPU我们需要了解CPU运行级别、使用率、上下文切换、运行队列、进程调度、系统调用、CPU管理（进程管理、taskset、intel VT-X），如taskset，把一个进程绑定在不同CPU的kernel上，来减少cache miss等等；内存需要掌握linux虚拟内存，以及SWAP换入换出、内存寻址、内存管理（Buffer Cache、HugePages、ksmd、EPT）；磁盘IO需要掌握缺页中断，如主缺页中断和次缺页中断，就是如何通过中断数据把磁盘数据载入到内存中，还涉及到IOPS（顺序IO、随机IO）、IO管理（IO调度算法、virtio）、VFS；网络IO需要掌握TCP/IP（三次握手、四次挥手、11种状态转换、TCP队列）、IO模型、网卡Bonding、Bridge、网络管理（iftop、tcpdump）；以前做运维时，经常会做一些内核定制，包括内核参数的优化，以及脚本编程（AWK、Sed、Shell、Python、PHP、Perl、Ruby、Lua），这是运维必须掌握的知识。

基础设施层

基础设施层有IAAS(基础设施即服务)，即有公有云、私有云（OpenStack/cloudstack+KVM/XEN、oVirt）、混合云；还有硬件管理，包括硬件选型、配件更换、资产录入、系统安装（Cobbler）、标签化、Raid构建、远程控制（KVM、iDrac、ILO、IMM）；以及IDC托管，包括需求分析、IDC选型、网络测试、谈价格、签合同、设备采购（原厂vs渠道）、机柜和机位规划。

此外，还有数据中心选址、制冷、供电、网络、运维等管理。

以上即为整个运维知识体系内容，在此基础上，还囊括了产品方面的知识，比如基于DevOps产品思路、自动化运维产品思路，还总结了测试和开发相关的知识，作为运维工程师，可能还要协助开发测试人员工作，比如使用TCPCopy协助测试做性能测试，还协助做监控、环境规划等。

如果你想要从运维工程师变成运维主管、运维总监，那么你必须要掌握运维管理必会的ITSM、ITIL V3、IT Service CMM、Six Sigma、DevOps Master、项目管理（PMBok）、架构层面（知识体系、运维方案、容量规划、灾备规划、服务降级）等知识。

运维的发展趋势从小公司打杂开始，进而发展到运维开始分层，很多公司分为基础设施运维、系统运维、应用运维、运维开发、机房运维等，再进一步运维开始分场景分业务了，比如直播点播的运维、CDN运维等，最后，运维都是要实现自动化、智能化。

整个运维知识体系并没有严格的上下层级关系，除了整个体系之外，我还在每一层面编写了对应的监控体系、自动化体系和云计算体系。

缓存知识体系

除了运维知识体系，接下来向大家介绍缓存知识体系。

缓存知识体系包括用户层、代理层、web层、应用层、数据层、系统层和物理层。其中包括DNS缓存、浏览器缓存、反向代理缓存、解释器和web服务器缓存、动态内容缓存、页面静态化缓存以及local cache，还包括数据库缓存、操作系统中CPU和内存缓存，物理层有Raid卡和磁盘缓存，默认情况下磁盘缓存都是关闭的，在Raid卡中控制，Raid卡中有电池，机器如果断电，所有数据都可以保留。整个缓存知识体系不包含缓冲，只有cache，没有buffer。

提问式工作法（灵魂八问）

检验我们工作做得如何最好的方式就是提问题。以下总结出如何快速评测公司自动化运维承受度的灵魂八问。

问题：如果将生产中一台Web服务虚拟机直接删除掉，是否可以使用自动化手段恢复？通过这个问题来检测公司自动化运维承受度。

1.是否能够自动化创建一台新的虚拟机？

打开阿里云云主机，点击新建控制台这不算是自动化创建，调用阿里云API自动化创建可以。

2.是否能够自动化配置应用运行环境？

将它做成虚拟机镜像也可以。

3.是否能够自动化部署应用的当前版本？

4.是否能够自动化添加监控？

监控包括主机监控、应用监控和应用运行环境监控。

5.是否能够自动化完成日志采集？

人工登录做配置进行日志采集是不可以的。

6.是否能够自动化执行冒烟测试？

7.是否能够自动化添加新节点到集群中？

8.以上所有步骤是否涉及到CMDB的资产添加和状态变更。

很多做自主化运维都有CMDB，从第一部开始，CMDB里就有一个新的资产产生，随着2、3、4、5、6、7的状态变化，资产的状态是否发生变更。

灵魂八问其实是一个自动化场景，如何去评估你的自动化做得好不好，就是要看整个场景中是真自动化还是手工的。之前我们有很多自动化工具，很多企业把自动化工具玩转的都很好，但是工具自动化并不是真正意义上的全链路自动化。如果你使用k8s，这八问你可能会得5分，比如第一步，一个pod挂了会自动创建一个新的，第二、三步，k8s会把运行环境和代码都打包到docker镜像中，第七步，k8s会自动发添加新节点到集群中，我们再努努力，就会保证5分及格。

运维趋势和挑战

企业多云战略不可忽视

现在很多企业都在考虑多云战略，根据第三方统计，有84%的企业考虑多云战略，其中，有9%考虑多个私有云，17%考虑多个公有云，58%考虑用混合云。

容器化趋势不可阻挡

经过2019调研，66%企业正在使用容器，其中60%企业在使用kubernetes做容器编排，还有27%正在计划使用它。因此，容器已经成为一个大的发展趋势。

DevOps挑战必须面对

很多人觉得DevOps比较虚，都是忽悠人的，其实不是。从CI、CD到CO，持续集成、持续交付/持续部署到持续运营，包含了从计划、编码、集成、测试、发布、部署到运维整个应用开发和服务的生命周期。DevOps实际上是把应用和服务的生命周期关联起来了，希望大家必须去面对这个趋势，不要逃避。

运维转型的盛宴不要缺席

运维研发工程师这个职位未来会更名，因为未来所有运维都将具备研发能力。“会写python的人没什么了不起”，会的人可以用来自嘲，不会的人哪来的勇气说？我们要将自己的观念从传统运维向新运维方向去转型，可以参考google的SRE如何去做运维变革的，现在很多企业也在从事AIOps方面的内容。