作者简介
余何，在运维领域耕耘十余载，07年加入到平安集团旗下的科技公司。2011年，主导集团内***的应用迁徙与架构变更；2012年开展IT运维管理变革，打通横向条线，实现技能融合。光阴荏苒，日月如梭，运维往事历历在目，流过汗，熬过夜，摊过事，也拿过奖，运维是一个从无到有、日积月累、不断提升的过程，也是一个需耐得住寂寞，顶得住压力的行当，在此与正奋斗在运维一线的伙伴们共勉。
“工作不代表你，银行存款不代表你，你开的车也不代表你，皮夹里的东西不代表你，衣服也不代表你，你只是平凡众生中的其中一个。”
————电影《搏击俱乐部》
前言
运维人员在忙碌的工作中要面对各种“新概念”潮汐般地冲击，他们不得不放下精细化的脚本编程，丢下原生态的性能调优方法，随大流的淹没在这瞬息万变的“新时代”，运维水准的高低与这些新概念也扯上了关系，久而久之我们居然忘了运维的本质是什么。
运维到底需要什么
看看我们每天所做的，都是为了一个共同目标，让应用快速上线、稳定运行！那些广告术语：“弹性扩容、自助服务、按需分配”，以及“成本减少多少，效率提升多少”之类的陈词滥调与你并没有太多关系，不是吗?
实际上所有一切都是围绕着应用开展的，应用自身决定了快速而稳定的80%！面对一个庞大的、遗留的、冗余的、配置杂乱的CRM系统、ERP系统，无论外来新概念如何流弊也解决不了你任何问题，你唯一的出路是好好理解这个系统。
通过一些自动化脚本尽量的减少一些重复性工作，或者你强势的要求开发人员改造整个系统，采用全新的应用部署架构，但这又是公司层面问题。重要的事情再说一遍，关于自动部署、快速扩容方面，应用自身决定了80%。如果我们还不明白这一点，而迷信于什么互联网神器，那终将无功而返。
它可以给你什么
在基础架构引入虚拟化后，关于云的畅想一下子被点燃了，让我看看下面的图里：
云畅想
姑且让我们将虚拟化的引入定义为Cloud 1.0，这个时期将物理服务器资源拆解为隔离的虚拟计算单元提供给不同用户。对于不那么挑剔的用户，我们完全可以在一台物理服务器上的OS中提供多个服务给他，这肯定比虚拟化的资源使用率要来得高，但是，我们(运维人员)无法决定与控制应用特性，也就无法避免同一个OS中应用间的干扰，如此一来虚拟化的引入帮助我们解决了大问题。
对于中小企业停留在Cloud 1.0就足矣，而对于大型企业、互联网企业，他们很快发现其所管理的计算资源陡然上升。亚马逊Amazon率先将这种虚拟化资源商业化，通过集中管理界面对外兜售，而开源领域Openstack与各虚拟化组件集成，势必统一行业标准。
无论是公有云还是私有云，在这一轮Cloud 2.0的战役中，***的改变是组成了一个更大的虚拟化池，将虚拟机的资源申请、配置管理、服务计费等用另外一种方式加以呈现。而关于虚拟机(OS)之上的东西和以前并无太多差别。是的，亚马逊Amazon的公有云，他将平时“闲置”的资源兜售给了外部用户，国内大型“云”提供商，他们很可能是战略性的“占领”未来行业市场。
至于大多数企业内部的私有Cloud 2.0，则情况又完全是另一番景象。限于这个阶段大部分工作是重新梳理了一种配置管理、资产管理以及服务定价的方式，让我们将Cloud2.0定义为Resource-centric。
事物的发展总是向前的，尽管在发展道路上常会偏离轨道，但总将回归本位，运维的本质是让应用快速上线、稳定运行，对于一个应用本身高度可控的企业，它们选择了更进一步，让应用适应平台，在公有、私有IaaS上构建Application-centric的Cloud 3.0，亦即PaaS。
在公有、私有IaaS上构建PaaS
PaaS运维服务的本质
PaaS并不是解决一切问题的灵丹妙药，它专属于特定领域，这个领域与应用部署架构、业务场景等紧密相关。如果你发现组织中有大量需要互联网化的应用场景，它们大部分集中在渠道领域，要求应用加快测试、发布效率，要求随时进行快速扩容，那么我们可以考虑构建自己的私有PaaS，它可以管理公、私有IaaS资源(虚拟、物理)。
PaaS在业界的标准并未统一，而充分发挥PaaS优势的很大一部分决定于应用部署架构。如果你有一个时髦的开发团队，他们遵循去中心化、异步消息通信、无状态等原则部署应用，那么你可以轻松的将其推送到PaaS。反之，如果有着一大堆跑在Window操作系统上的窗口应用，好吧！PaaS再神奇也于事无补。
至此，让我们看看在OS之上，运维服务要解决的问题：
1.资源分配
我们大部分时间在进行资源分配，将服务器、存储、操作系统以及软件等分配给应用，工作的复杂性围绕着应用而产生。
2.应用部署
将开发兄弟提供的业务逻辑放到我们所分配的资源中去。
3.服务发现
如果让用户找到这个服务，如何让服务于服务之间可以互访问。通常的做法有负载均衡、域名解析、配置消息中心等方式解决服务发现问题。
4.监控巡检
监控巡检是运维之必须，在此不再累述。
在这里，我们讨论前三项，资源分配、应用部署于服务发现。
PaaS平台功能设计
为了能够实现PaaS平台，我们需要保证运维的四个主要工作内容实现自动化，下面这些功能全都是围绕着实现这个目标而引入的。
1.计算单元打包
虚拟机镜像、配置管理工具(puppet、saltstack、ansible)所负责的任务就是将应用逻辑计算单元进行打包。计算单元包含了运行业务系统的全栈组件，其涵盖了操作系统、中间件、依赖包等。
PaaS平台中，我们选择Docker替换原有的方式，作为一个轻量级容器，它比虚拟机更加节约资源，同时可以基于一份软件介质运行多个实例，Docker的仓库、镜像与容器三元素让应用逻辑计算单元大大得到了简化。
诚然，ansible这类软件配置工具已经非常轻巧、快捷，并且满足95%以上的需求，但当决定将PaaS构建在跨IDC、跨第三方数据中心时，基于镜像的分发能够更加稳定的满足我们需求。Docker也有其缺点，例如不支持32位平台，不支持windows服务器。
Docker+Ansible 完成计算单元打包
2.资源动态分配
与Cloud 2.0的IaaS不同，用户并不关注如何获得CPU、内存、存储资源。他们仅关注自身应用计算逻辑的运行，他们希望资源是动态分配、弹性扩容的。
数据中心需要一个统一的资源管理者，它将所有资源(无论虚拟、物理)抽象成一个整体，如同一个数据中心操作系统。这种资源的抽象不仅仅要满足服务型计算，还要满足大数据时代的MapReduce计算，以及今后的各种类型计算，这意味着资源分配与任务调度两部分功能是解耦的。
在分布式资源管理领域，主流的选择是Mesos、YARN。
◆ Mesos：Mesos最早由美国加州大学伯克利分校AMPLab实验室开发，后在Twitter、Apple、Netflix等互联网企业广泛使用，成熟度高。
◆ YARN：Apache Hadoop YARN是一种新的 Hadoop 资源管理器，它是一个通用资源管理系统，可为上层应用提供统一的资源管理和调度。
其他的选择还有Kubernetes、CloudFoundry、OpenShift等方案，但这几种不满足资源分配与任务调度解耦，对应用规则要求太高，并不容易兼容现有应用。在我们环境选择了Mesos，其独有的灵活性保证了支持更多类型的上层分布式计算应用。
Mesos 分布式资源管理
数据中心OS
3.任务调度功能
任务调度器与资源管理器的***不同在于其要对运行中的应用服务负责，包括启动、停止服务，监控服务以及在服务失效时的故障转移。最初的分布式架构设计中，人们常常模糊了作业调度与资源管理二者间的界线。
其一是分布式平台是为某一专属计算类型服务，例如Hadoop平台为MapReduce计算类型服务。
其二，作业调度与资源管理的交互频度高，合二为一后的效率更高。但随后人们发现资源管理器的功能是相对稳定的，而作业调度因为计算类型多。
并行计算有MapReduce、Stream，普通计算有Service、批处理等，每一种计算类型的作业调度方式完全不同，如果将资源管理器与作业调度器绑定在一起则会失去分布式平台的计算灵活性。
是以Mesos为核心，支持多领域的分布式集群调度框架，包括Docker容器集群调度框架Marathon、分布式 Cron(周期性执行任务)集群调度框架Chronos和大数据的主流平台Hadoop和Spark的集群调度框架等，实现系统的资源弹性调度。
Mesos架构示意图
对于服务型的长任务，我们选择Marathon作为其任务调度器。
Marathon任务调度
4.服务发现功能
服务发现有两种形态，一种是用户(人)来访问的，一种是应用之间互调的，对于前者需要保持一个稳定的入口(不变)，而对于后者，如果在一个宽松的环境里，是运行变化，并接受变化通知的。而对于长服务型计算类型，除了解决服务发现外，还要考虑将任务分发到多个节点，亦即负载均衡问题。
服务发现上可选的有通过动态写入DNS系统来满足用户需求，通过zookeeper之类的分布式协调系统充当配置中心通知外部系统。而在负载均衡上，企业级的专用设备，例如F5等都提供了API接口以供调用，而开源软件上通常采用Haproxy。
通过zookeeper实现服务发现
Marathon的Haproxy服务发现方案
5.日志集中管理
在一般情况下，日志以文件的形式存放在本地操作系统上以供查询，而在分布式系统中，计算单元不会再固定于一个物理节点上。如果日志仍以文件形式存放在本地，随着计算单元的漂移，日志将留存在与计算单元没有关系的物理节点上。对于系统管理人员、运营人员来说，日志查询检索将变成一门繁杂工作。
在分布式平台上构建集中的日志管理平台，将各种类型的日志收集、索引好，以消息的形式看待每一条日志将成为分布式平台上的一个重要功能。采用开源社区流行的ELK组件(elasticsearch、logstash、kibana)，我们会看到如何将所有节点的日志导入到一个集中平台进行可视化管理。
elastic日志集中管理
PaaS下的运维发展之路
PaaS时代的来临，对运维职业发展将产生深远影响，一个严重的误区是认为云计算将彻底取代运维行业，实际上在IT发展的过程中，对运维的要求在不断提高。云计算、大数据、物联网以及移动互联等无一不是这个时代向前发展的标志， 只要IT越贴近用户，就会产生更多的数据、发现更多的需求，运维则愈加之重要。
运维职业发展的三个硬道理是：
1.不变应万变
要做到不变应万变，就必须掌握业内最基础、最稳固的知识点，打下结实的基础。相对于开发应用框架、前端UI的变化，存储、计算、网络三大资源知识是非常稳固的，即便是变化也一定是建立在基础原理之上。
互联网变化之快，新技术层出不尽，运维人员不能太过于跟风，一定要看清事物背后的本质，与基础原理相联系，深入底层内部思考，这样才能做到万变不离其宗。以Linux操作系统为例，运维人员并不需要将所有发行版的安装、命令等背诵入流，而是精通一到两种，并通过操作系统的运行原理来解释一切问题。
2.精通编程
不会编程的运维人员不是好运维，在开源风潮涌现的年代，可以预见未来对运维人员的开发能力要求会非常之高。系统开发与应用开发在完全不同的两个维度，系统开发更贴近于底层，掌握程序的运行原理对编程能力的提升有极大帮助，例如可执行文件的结构、在内存中的形态等。
运维人必须精通一门编程语言，参与到社区，品读开源代码，养成编程习惯。引用Linux之父Torvalds的一句话“just for fun” ，这是运维人看待编程应保持的心态。
3.敏锐观察力
时代依然在不断变化，运维人虽不必立即掌握每一项新出炉的技术，但他们必须保持对行业的关注度。预留一些时间给自己阅览社区新闻，积极参加线下社区活动，随着新技术的成熟以及自己的个人兴趣，在新兴领域投入必要的时间。
Larry Wall是Perl语言的设计者，他属于运维鼻祖，也就是系统管理员。当时Larry遇到了一个问题，如同我们现在遇到的一样。他需要在繁杂的内容中萃取文本信息，而手头的工具只有awk和shell这些工具可以帮助解决问题。
这些工具用起来却是那么痛苦，Larry太懒了——如果用awk来做的话，要做大量工作，这让他无法忍受；Larry也太急躁——awk做起来很慢，他可等不及；最终他的高傲促使他完成了一件壮举，设计一门新语言——Perl，造福整个社区。是的，你会发现运维时代在变，但同样的故事还在发生，你是否已做好准备?
