作者简介 于贺，在运维领域工作十余年，2007年加入平安集团旗下科技公司，2011年主导了国内最大的应用迁移和架构变革群组;2012年进行IT运维管理改革，打通横向线路，实现技能融合。光阴似箭，日月如梭，运维往事历历在目。流过汗，熬过夜，分享过东西，拿过奖。是一个耐得住寂寞、耐得住压力的事业，在此鼓励奋战在运维一线的小伙伴们。 “你的工作不代表你，你的银行存款不代表你，你开的车不代表你，你钱包里的东西不代表你，你的衣服不代表你，你只是普通人中的一员。”——————电影《搏击俱乐部》 前言 运维人员在繁忙的工作中不得不面对各种“新概念”的潮汐冲击。他们不得不放下精炼的剧本编程和原生态的表演调整，用最好的方式淹没在这个瞬息万变的“新时代”与潮流之中。运维水平也和这些新概念有关。久而久之，我们其实忘记了运维的本质是什么。 运维到底需要什么 看看我们每天都在做什么，都是为了一个共同的目标，让应用快速上线，稳定运行！那些广告术语：“弹性扩展、自助服务、按需”和“节省成本、提高效率”这些陈词滥调并不真正让您很在意，不是吗？ 全部都是围绕应用开发的，应用本身决定了80%的快与稳定！面对庞大、遗留、冗余、杂乱无章的CRM系统和ERP系统，国外的新概念再烂也解决不了你的任何问题。你唯一的出路就是很好地理解这个系统。 使用一些自动化的脚本来减少一些重复的工作，或者你强行要求开发人员改造整个系统，采用新的应用部署架构，但这是公司层面的问题。重要的再说一遍，应用本身决定了80%的自动部署和快速扩展。如果我们还不明白这一点，迷信一些互联网神器，最终会白白返回。 它能给你带来什么 在基础设施引入虚拟化之后，关于云的想象顿时被点燃，我看下图： 云想象 引入虚拟化是定义为Cloud1.0。在此期间，物理服务器资源被拆解成孤立的虚拟计算单元，提供给不同的用户。对于不那么挑剔的用户，我们可以在一台物理服务器上的OS中为他提供多种服务，这肯定比虚拟化的资源占用要高，但是我们（运维人员）无法决定用Controller应用特性使之同一操作系统中的应用程序之间的干扰是不可能避免的，因此引入虚拟化可以帮助我们解决大问题。 中小企业留在Cloud1.0就够了，但是对于大企业和互联网企业来说，他们很快发现自己管理的计算资源急剧上升。亚马逊率先将这种虚拟化资源商业化，并通过集中管理接口对外销售，而Openstack与开源领域各种虚拟化组件的整合势必统一行业标准。 无论是公有云还是私有云，在这一轮Cloud2.0战役中，最大的变化就是形成了一个更大的虚拟化池，集虚拟机的资源申请、配置管理、服务计费等于一体以另一种方式呈现。虚拟机(OS)上的东西与以前没有太大区别。对，亚马逊亚马逊的公有云，他把平时“闲置”的资源卖给外部用户，国内大型“云”提供商，他们很可能战略性地“占领”未来的行业市场。 至于大部分企业内部的私有云2.0，情况就完全不同了。局限于这个阶段的大部分工作是重新组织一种配置管理、资产管理和服务定价的方式。让我们将Cloud2.0定义为以资源为中心。 事物的发展总是向前发展的。发展道路虽然时常偏离轨道，但总会回归本位。运维的本质是让应用快速上线，稳定运行。对于本身应用可控性强的企业，他们选择更进一步，将应用适配平台，在公有和私有IaaS上构建以应用为中心的Cloud3.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%以上的需求，但是当决定跨IDC和第三方数据中心搭建PaaS时，基于镜像分布可以更稳定的满足我们的需求。Docker也有它的缺点，比如不支持32位平台，不支持windowsserver。 Docker+Ansible完成计算单元打包 2.动态资源分配 不同于Cloud2.0IaaS，用户不关心如何获取CPU、内存、存储资源。他们只关注自身应用计算逻辑的运行，希望资源能够动态分配和弹性扩展。 数据中心需要一个统一的资源管理器，将所有的资源（无论是虚拟的还是物理的）抽象成一个整体，就像数据中心的操作系统一样。这种资源的抽象不仅要满足面向服务的计算，还要满足大数据时代的MapReduce计算，以及未来的各种类型的计算，也就是说资源分配和任务调度这两个功能是解耦的。 在分布式资源管理领域，主流的选择是Mesos和YARN。 ◆Mesos：Mesos最早由加州大学伯克利分校的AMPLab开发，后来被Twitter、Apple、Netflix等互联网公司广泛使用，成熟度很高。 ◆YARN：ApacheHadoopYARN是一种新的Hadoop资源管理器。它是一个通用的资源管理系统，可以为上层应用提供统一的资源管理和调度。 其他方案还有Kubernetes、CloudFoundry、OpenShift等方案，但这些方案不满足资源分配与任务调度的解耦，对应用规则要求太高，不易与现有应用兼容。我们的环境选择了Mesos，其独特的灵活性保证了更多类型的上层分布式计算应用得到支持。 Mesos分布式资源管理 数据中心操作系统 3.任务调度功能 任务调度器和资源管理器最大的区别在于它负责运行应用服务，包括启动、停止服务、监控服务以及服务失败时的故障转移。在最初的分布式架构设计中，人们往往会模糊作业调度和资源管理之间的界限。 一个是分布式平台服务于特定类型的计算，例如Hadoop平台服务于MapReduce计算类型。 其次，作业调度与资源管理交互频率高，两者结合后效率更高。但是后来人们发现，资源管理器的功能比较稳定，作业调度的计算种类很多。 并行计算包括MapReduce、Stream，通用计算包括Service、批处理等，每种计算类型的作业调度方式完全不同。如果资源管理器和作业调度器绑定在一起，分布式平台将失去计算的灵活性。 以Mesos为核心，支持多领域分布式集群调度框架，包括Docker容器集群调度框架Marathon、分布式Cron（周期性执行任务）集群调度框架Chronos，以及主流大数据平台Hadoop和Spark集群调度框架，等，实现系统资源的灵活调度。 Mesos架构图 对于服务型的长任务，我们选择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的话“justforfun”，这是运维人员在看编程时应该保持的心态。 3.敏锐的观察 时代还在变。运维人员虽然不需要马上掌握每一项新技术，但一定要保持对行业的关注度。给自己预留一些时间阅读社区新闻，积极参与线下社区活动，随着新技术的成熟和个人兴趣，在新兴领域投入必要的时间。 LarryWall是Perl语言的设计者。他属于运维的鼻祖，也就是系统管理员。拉里当时遇到了问题，就像我们现在遇到的一样。他需要从复杂的内容中提取文本信息，而手头的工具只有awk、shell等可以帮助解决问题的工具。 这些工具用起来太痛苦了，Larry太懒了——如果用awk来做，会很费功夫，让他受不了；Larry也太不耐烦了——awk很慢，他等不及了；最终，他的傲慢驱使他为了整个社区的利益而设计了一种新语言Perl。是的，你会发现运维时代在变，但同样的故事还在上演，你准备好了吗？
