运维要做的事情，实在太多了。
说复杂，复杂得没有人能说明白，列举全面。
说简单，倒也简单：运维工作就是支持生产运行，是成本中心，一般不直接产生利润。目的就是运行保生产设备软硬件正常运行，让内外部用户满意度。
运维要做的事情与岗位职责内容密切联系，可能有了运维要做的事情需求，因此设置了岗位和人员，但也有因为有了这个岗位的人，因此创造了一些运维事情。
这有点“鸡生蛋、蛋生鸡”的逻辑。
1
运维系统架构
每个公司的IT 环境，不论大小复杂度，总会有个系统架构层次。有了这个架构体系，那所有的运维事情大体都围绕着这个系统架构上的每个元素及整体进行运维保障工作。运维架构从某种角度可以划分为如下两种：商业封闭式系统架构（IOE 架构）与开源系统架构。
- 商业封闭式系统架构（IOE 架构）
典型的即以使用IOE（IBM、Oracle、EMC）产品软硬件为主要元素的系统架构。IOE 架构以纵向扩展为特点，通过增加CPU、内存、扩展柜、冗余备件等方式来提高处理能力及稳定性。该架构的处理能力主要取决于单台（套）设备（系统）的最大扩展能力，很难通过增加设备（系统）数量来增加处理能力，换句话说该架构很难通过扩大集群规模的方式来解决问题。随着纵向扩展的规模增大，其实施技术难度、管理复杂度以及隐患风险都会正比例大幅上升。基于IOE架构的典型企业如金融业、电信业，交通运输业。
IOE 典型的系统架构
上述IOE 型系统架构。其服务器多使用小型机、大型机（还有以往的中型机），数据库系统往往会使用Oracle，存储则多使用知名品牌的中高端存储阵列、带库等设备。服务器与存储之间多使用SAN 存储网络。这些服务器、存储等硬件本身往往就是双冗余的，线路连线也都是双冗余的，而且设备性能指标往往非常好，例如一台普通中端的Power 7 系列服务器可以轻松划分出若干个系统分区或者一二十个虚拟机系统。
- 开源系统架构
典型的即以使用廉价PC 服务器、开源产品技术为主要元素的系统架构。开源系统架构以横向扩展、分布式部署为特点。通常通过往集群中增加单机设备资源解决存储空间、性能以及稳定性问题，其集群规模可以小到由两三台PC 服务器组成，也可以大到上万台PC 服务器集群。
对于数据库，可以通过分布式集群方式解决数据库扩展性的问题。另外非结构化数据库及分布式文件系统在处理非结构化数据的存储与使用方面也很灵活方便。基于开源系统架构的典型企业如以BAT（百度、阿里、腾讯）为代表的众多互联网企业，开源系统架构如下图所示。
上述开源系统架构中使用了CDN 和反向代理以提高网站性能。例如我们的服务器可能部署在北京，对于北京及周边用户来说访问是较快的，而对于远离北京的用户访问则感觉较慢，因为数据传输时间比较长。对于这种情况，常常使用CDN 解决，CDN 将数据内容缓存到运营商（或自建CDN）的机房，用户访问时先从最近的CDN 机房获取数据，这样大大减少了网络访问的路径。比较专业的CDN 运营商有蓝汛、网宿。
对于反向代理，当用户请求达到时首先访问反向代理，反向代理服务器将(Varnish)缓存的数据返回给用户，如果没有没有缓存数据才会继续走应用服务器获取，这也减少了获取数据的成本。当然对于海量访问请求，或者庞大集群架构，则就需要分多层、综合运用上述负载均衡以及代理（反代理），同时可能需要引入Zookeeper 等功能以协调（服务）任务调度。
关于去IOE 问题，本文简单阐述如下。
近年来开源技术的迅猛发展，以及国内外政策环境共同作用，引发了一场去IOE 的风潮，其中以阿里巴巴发动的“去IOE”运动较为著名。他们使用低廉的软硬件产品代替昂贵高槛的IOE 产品，搭建起自主开放的开源系统架构。之所以出现“去IOE”运动，其中原因总概述如下几条。
- 自“棱镜门事件”之后，国家强烈意识到数据安全的重要性，开始大力提倡产品设备国产化与自主研发，这正与“去IOE”观点不谋而合，上下一致。
- 近年来，云计算、大数据等新兴IT 技术的蓬勃发展，促使众多行业开始往更加开放灵活的开放系统架构转型。这对于传统的IOE 架构而言，其定制与扩展灵活性有限，往往是擅长于集中式架构的管理，而很难应对大规模集群、分布式存储计算。在购买成本方面，以IOE 为代表的商业产品价格昂贵（动辄上百万元），PC 服务器相对廉价（通常几万元）。在部署与管理方面，IOE 产品的学习掌握门槛偏高，而开源系统环境相对容易搭建与管理。另外IOE 产品技术相对商业封闭，不易掌握。
基于上述一些原因，去IOE 应时而生。当然具体到自身企业是否要去IOE，这需要慎重考虑，适合自身发展需要的系统架构就是好的架构。去IOE 过程，其实是系统架构的更新换代，产品的更新换代，运维理念的更新换代，运维人员的更新换代，知识体系的更新换代，等等。因此如果贸然去IOE，可能既不会降低成本，也不会提高效率，更不会稳定架构。如下列举几点“去IOE”要考虑的因素。
- 自身业务是否真正需要大数据、云计算以及分布式这种海量运维体系。
- 是否已经考虑好系统架构、运维理念、人员、知识更新换代的方案。
- 自身的研发实力储备是否够解决大量开源产品的坑坑洼洼，并有实力搭建开源系统架构。是否有足够的资金应对“去IOE”转型中的成本，例如从硬件高成本转向人力技术高成本。
去 IOE 只是给予我们一些最佳实践与选择路子，但去IOE 技术门槛较高，一般企业很难复制。从目前发展来看，IOE 架构与非IOE 架构仍将长期并存。一时间很难找到一些能够完美替代以IOE 为代表的成熟（且普适）产品方案。
2
运维工作层次分类示例
例如《海量运维、运营规划》（作者：唐文）一书，作者很有观点地概括了运维要做的事情，他以质量、效率、成本为核心，从运营规划、管理、流程/规范、系统/平台、监控、告警、安全、优化、考核等几个维度来阐述运维工作。
另外也可以从逻辑框架的层次来分类运维工作要做的事情。如下借鉴美团的分享者（唐君毅、邱剑、朱晏）关于企业运维的观点，运维框架可以概括为五横三纵。从横向来看，自底向上分为五个层次。
- 物理层：包括机房网络、硬件设施相关工作。如采购招投标工作、机房实施工作、机房环境（强弱电、照明、通风、网络布线、温湿度等），各种设备上下电与维修工作等。
- 系统层：包括操作系统、虚拟化、云计算等一系列系统环境所涉及的部署、配置、优化等工作。
- 服务层：包括Webserver、缓存、代理、数据库等所涉及的软件应用的部署、配置、优化等工作。
- 逻辑层：包括业务逻辑、数据流。这一层的主要工作是发布和变更。
- 应用层：包括用户可见部分。所有前端平台，主要涉及与前端用户交互或提供信息（服务）的平台。比如前端网站、各种新媒体平台的维护与监控。
- 从纵向来看，有三部分工作，对上述五个层次是通用的。
- 监控：从物理层到服务层的监控和报警都是运维来跟进、响应的。对于逻辑层和应用层，一般由运维提供监控API 的规范，开发人员自己创建监控项、设定报警规则、进行增删改查。
- 安全：建立部署统一的安全接入平台，所有线上的人工操作都需要登陆跳板机，每个人有独立的登陆账号，所有线上操作都有审计日志。更多的安全工作由专门的信息安全组负责。
- 流程：早期基于Jira做了一些简单的流程，但需要改进。现在正在针对比较集中的需求，开发相应的流程控制系统，方向也是自动化、自助化。从业务部门申请VM 资源，到业务扩容的整个流程，未来可以在Web 界面上通过很简单的操作实现，也提供服务化的API，方便其他业务平台进行集成。以期实现虚拟化覆盖全业务线。
做好日常基础运维工作，保障好生产业务运行。不断探索新的运维理念与技术，探索优化系统架构。最重要的是要运维明白什么是正确的事，怎么正确地做事，做事有章法，才能实现稳定高效能。
本文选自《系统运维全面解析：技术、管理与实践》
