作者介绍​

张延礼，现苏州蜗牛高级运维经理，就职于腾讯多年，熟悉基础架构运维及业务运维，在运维技术实施、流程及标准化体系建设、运维自动化架构设计及实现，运维支撑体系规划和执行团队管理等方面具有丰富经验。

正文

本文基于蜗牛从零开始建设运维自动化的一些实践，总结自动化建设过程中涉及的体系规划、实施路线、产品设计及架构设计等方面的经验。

一、自动化体系规划

1、自动化要解决什么问题

运维层面的工作可以归结为如下三大块

服务管理层面主要是从运维总体支撑的角度来管理运维质量、规范、成本等等，处在运维工作的最高层；技术决策主要是为实现管理目标去制定总体方案，实施路径；技术执行则是落地的最后一环，这一环工作往往呈现零散、杂乱、重复、频繁变更的特点，承接的需求量最多，但价值体现却是较低的一环。

当前运维自动化的首要目标还是在解决”技术执行”这一层面的问题：将大量重复低价值含量的人力实施变成自动化执行，最大化地降低人力依赖，提升运维效率及业务支撑能力。

2、自动化建设思路

对于如何建设自动化运维，个人认为首要的是要有建设思路与方法论，以下供参考：



3、自动化建设总体框架

自动化的建设水平在行业内差异化还是明显的，如果处于运维自动化起步的阶段，建议是组建运维开发团队，从整体规划，基于ESB思想，分层建设，让支撑平台从业务逻辑中解耦。比如就业务运维而言，整个操作工作面无非就是对业务运营环境的各种操作、配置，以及对业务应用程序的管理，简单来说就是OS层和应用层。

要做自动化实施首先得有准确对称的数据，然后需要一个统一的管控平台，能并发的控制和操作远程大量主机，这解决了OS层面的操作问题，但需要管理应用层面的东西还需要与应用的研发人员规范相关接口，这对于开源组件应用而言一般不会有什么问题。因此如果是从零开始做自动化，个人认为CMDB、管控平台、业务进程管理工具这三部分是地基。在此基础之上，可以针对运维各类场景和业务逻辑去做相应的垂直功能系统，再上一层，可以使用流程引擎之类的组件来实现业务运维流程的纵向整合，最终实现运维各类业务流程的纯线上自动化。
 

二、自动化实施路线

业务发展往往带来运维块面的应用形态、运营环境、、部署结构、基础架构规模及组织流程等多样化、复杂化；如无统一的标准及规范，运维支撑工作将异常混乱，自动化也难以实施。因此自动化有一个基础:标准化，标准化是将一切杂乱无章、千头万绪的运维工作变得有序及可控，流程规范与执行标准的落地是自动化的一大基石。结合我司实际运维现状及需求，基于以上自动化体系建设思路，前期规划的建设线路如下

1、信息的标准化管理：CMDB

在运维工作中，信息的管理往往是难点，运维侧涉及的信息太多，且也与其他职能部门多点关联，信息流转于整个流程的多个职能部门、多个环节

中小型企业中，手工线下记录的方式居多，线上线下信息一致性保持、内部外部信息传递、共享、同步等均存在较大问题，经常出现:

• 线下表格有，实际位置找不到，或信息不对称
• 不清楚设备状态，不清楚哪个业务在使用
• 一个部门做了变更，其他部门不知情
• 变更一条上联链路，无法及时判断影响范围及程度

根本问题及给运维工作带来的痛点如下 因此我们引入一套基于ITIL体系的配置管理数据库CMDB，旨在为运维团队建立线下与线上一致性的基础信息库，作为运维标准化、自动化、平台化的基础输入。重点解决IT基础架构信息化以及业务配置信息线上化，系统主要功能模块如下图: 系统本身主要功能可归结为2个方面：基础架构信息管理、业务信息管理。此两大方面的功能使用者为web-user，除此之外，对于API-user，此系统提供了一整套接口界面与其它任何需要信息的系统进行对接，这也是设计初衷，将信息从一个统一的、标准的源头输出给各垂直或水平业务功能系统，而运维需要做的就是维护CMDB本身基础数据的完整性、准确性，CMDB与各流程系统、垂直功能系统结合之后实现信息数据一处变更，处处同步。 如上为CMDB业务管理模型，作为运维统一信息库，与其他系统平台数据互通，深度整合后实现信息的管理、维护、展现全部线上化。产品设计过程中涉及的几个关键点：

• CI及属性需要贴合实际环境，同时考虑长期的运维规划
• 管理的不仅是CI及其属性，还有CI之间的关系，状态流转机制等等
• 充分考虑扩展性及灵活性，如引入自定义属性来满足未来或暂时不可预见的需求

 2、通用型作业平台对于运维执行工作而言，绝大部分的实现均是对运营环境的各类操作，在业务体量上去后，需求导致的运维操作密集度不断增加，如公司内某款游戏业务部署在近上百台主机上，一次维护要对此上百台逐一进行相应的操作，如通过人工去完成则费时费力、效率低下、且影响业务可用性。由此运维面临的问题是： 我们决定做一个通用型运维操作平台来解决这些问题，为运维人员提供一个可以批量控制和操作大规模主机的通道，运维人员在web界面中可以定制所有的运维操作，指定执行的对象，通过平台下发执行并返回结果，例如 批量shell脚本执行，大量文件传输，发布变更，数据备份等等各类场景。对于产品设计上遵循以下几点: 技术实现上，基于公司运维环境，我们对后端系统有如下需求：

• 良好的scale-up/scale-out，灵活扩展，支持复杂网络结构
• 轻量级、高效的后端通信机制，成千上万的管理规模
• 跨平台，支持windows、unix-like多平台，无需重复开发

运维门槛低，使用运维熟悉的命令操作及脚本语言即可完成一切作业，无需学习众多的特定模块或yaml语法,为此我们迅速找到了saltstack作为后端系统；前端系统涉及到的交互逻辑及业务逻辑自主研发，自研部分需实现的逻辑如下：

• 全网统一的一套基于web的用户界面，将所有操作逻辑通过web层来调用salt-api，web前端提供与直接登录机器操作一样的灵活性和自由度，运维人员在web上完成所有操作。
• 对运维操作进行建模，将其分解为几大原子操作类型，一切复杂的序列化操作逻辑可通过原子的自由组合来实现，给用户提供自由灵活的操作方式
• 基于以上逻辑，再给salt加一层应用接口，便于后续其他系统平台可直接调用或整合UJOBS以建设更高层次的平台。

后端salt的逻辑这里不赘述，由于实际网络环境的特殊性，我们采用了二层架构，即master-syndic-minion,公网与内网相结合的方式最大限度提升系统性能。

权限控制、执行对象等等与CMDB打通，可以非常灵活的适应各类业务，各种场景。

如运维人员可以在界面定义好一个版本发布作业：xx业务发布，分解整个发布流程中到每一步骤，并写脚本或调用外部接口来实现具体的操作，最终线上操作只需在页面点击开始执行就可：

当然用户自定义作业可以复用，通过传参的方式实现实例化，避免必要每次发布都建作业。
 
3、建设过程中的问题总结
 
做好产品设计及架构设计
充分解析运维内部需求，各具体平台或产品业务区分明确，产品定位一定要清晰，不要想着让微波炉具备电冰箱的功能，自动化整个体系不是一个产品能解决所有问题，需要自顶向下分层设计，产品之间相互解耦且又对外提供接口，能方便的整合与被整合。

组建运维内部开发团队
运维自动化的建设，最好是组建运维内部团队来进行开发，直接丢给业务研发部门往往做出来的东西不是运维侧想要的，因其不易理解运维侧的需求场景、痛点，操作方式等等；如实在没有运维开发团队，那就找个深度理解运维场景的PM去跟开发团队吧。

推动业务开发侧的标准化
其实产品开发团队的研发管理水平及标准化程度直接决定了运维人员爽与不爽，绝大多数研发人员往往只考虑产品功能实现，而很少关注可维护性设计，导致业务给运维人员带来很大的无价值工作量，更有甚者直接是将运维人员当成代码逻辑的一部分。让运维人员参与产品研发的可维护性设计是很多必要的，运维侧需形成可维护性标准规范，推动业务开发遵循将非常利于运维自动化的建设。

文章来源：微信订阅号"运维帮"
地址：http://dwz.cn/6c2Yqz 

急需转型的企业IT服务
 
在企业里，IT部门一般是作为服务部门而存在，大部分企业IT部门是以提供基础架构服务和通用IT服务为主，如何提高系统的可用性和提升响应速度就变成IT服务管理内容的核心。
 
目前，国内企业的IT管理经历了系统管理、网络管理之后，现在正逐渐向IT服务管理阶段过渡。但许多企业IT服务远没有实现主动式管理，依然停留在服务支持管理的层面上。
 

IT服务管理的必要理念

目前，IT已成为许多业务流程中必不可少的部分，IT服务地位的提升意味着IT要承担更大的责任。一方面，IT必须满足业务流程不断变化的需求;另一方面，IT服务的相关成本也要随之不断降低。但是我们看见，IT在这两个方面都没有做出令人满意的答案。
 

IT服务管理的根本目标

IT服务管理的根本目标有三个：

• 第一，以用户为中心提供IT服务
• 第二，提供高质量、低成本的服务
• 第三，提供可量化计价的服务。

如果简单说明，IT服务管理可概括为"二次转换"，第一次是"梳理"，第二次是"打包"。
 
首先，将纵向的各种IT技术管理工作(传统IT管理的重点)，如服务器管理、网络管理和系统软件管理等进行“梳理”，形成典型的流程，这是第一次转换。这主要是供IT部门内部使用，用户对此并不感兴趣。但是，仅是这些流程还不能保证服务质量或客户满意，还需将流程按需”打包“成特定的IT服务，提供给用户，这是第二次转换。
 
简单来说，第一次转换是将IT技术管理转化为IT流程管理，第二次转换是将IT流程管理转化为IT服务管理。
 
从用户的角度来说， IT只是提高运营业务效率的一种工具，用户不需要对IT有太多的了解，用户需要的是IT所实现的功能。用户和IT部门之间的交流，使用的是”商业语言“而不是”技术语言“，IT部门需要向用户提供的是 IT服务。
 
为了能够灵活、及时和有效地提供IT服务，并保证服务质量、理化计算有关成本，IT服务就必须事先对服务进行一定程度上的分类和打包。

 

ITIL高效解决IT服务问题

ITIL的全名是IT基础设施库，简单的说，就是一套针对各行业的IT服务管理标准库。 ITIL结合流程、人员和技术三要素，为企业的IT构建一套从计划、研发、实施到运行维护的最佳实践方案。
 
一套协同流程是ITIL框架的核心，它通过服务级别协议(SLA)来保证IT服务的质量。它融合了系统管理、网络管理、系统开发管理等管理活动，以及关于变更管理、资产管理、问题管理等许多流程的理论和实践。
 
ITIL提供的是一种流程处理的IT服务管理方案，它通过工作单形成IT服务流程闭环，以确保整个IT服务过程有据可查。同时，ITIL还制定了明确的服务流程规范，员工需要严格按照流程进行操作。ITIL不断高效地解决IT服务问题，提高IT部门服务效率，以此使用户感到满意，从而达到优质的服务。ITIL是一个很好的手段， 它简化了IT服务管理，变得优质与高效。

 建立高效能IT服务告别危机时代
 

清晰IT服务质量SLA目标

IT服务的质量目标是各方对IT服务管理的期望，它是业务部门和IT部门双方根据业务目标制定的。一个好的IT服务目标要有这几个方面的作用：明确持续服务管理，改进活动的方向;促使有关人员朝正确方向采取行动;协调不同人员的多个行动;简要有力地说明高层管理者的意图。
 

分析IT服务管理的现状

评估企业目前的IT服务管理现状和成熟度级别是核心步骤之一。ITIL自我评估手册提供了一个全面的评估方法。因为，用户的需求和IT服务现状是决定所提供IT服务的基础，而服务流程、职能、技能、企业结构和文化等则是根据用户需求和所提供的服务类型决定的。
 
分析和评价的现状要从这几个方面考虑：IT部门是否理解业务战略和方向、业务面临的问题;IT部门是否理解技术对业务的作用;IT部门和业务部门对当前IT服务成熟度和IT服务质量的看法是否一致;IT部门是否清楚了解利益相关者的需求; IT部门是否清楚了解不改进IT服务质量的后果等。
 

制定高效的IT服务管理方案

管理方案包括两个方面，一是选用何种服务管理工具，二是进行教育、培训、文化变革。经验表明，成功的IT服务管理实施，更多的是要依靠后者。
 
这一阶段的IT服务工作包括以下几点：
文件和制度制定：主要有IT制度文件准备、编制用户手册、工作记录手册及IT管理人员工作指南等。
员工培训工作：对与IT系统相关的每位员工都要进行适当的培训，一方面是对IT人员要加强业务知识技能的培训，理解业务原理及本质

对业务人员要加强IT知识技能的培训，通过培训可以使IT业务人员都能理解IT服务管理各流程的基本原则。
 
关键成功因素和绩效指标决定IT服务考核标准
 
检查IT服务效果是保障IT服务高质量的关键过程之一。这需要事先明确定义一系列可测量的目标和指标，然后在每个时期内进行评审，检查IT服务目标是否达到，服务质量是否得到提高。否则，就需要提出和采取补救和改进措施来实现预期目标。

因此，可以先为每个IT服务确定和定义一些关键成功因素(CSF)和关键绩效指标 (KPI)。关键成功因素是使每个IT服务达到高质量所需达到的最低要素，关键绩效指标是测量每个关键成功因素是否实现的具体数量指标。关键成功因素和关键绩效指标建立了每个IT服务的绩效考核基准。
 

总结

俗语说：创业难，守业更难。逆水行舟，不进则退。先前的IT服务活动已经达到目标，继而就要巩固取得的成果并采取进一步的改进行动。我们必须明白一个道理，提高IT服务质量是一个永无止境的持续过程。

摩卡业务服务管理(Mocha BSM)能够监控基础设施和应用，也能够将复杂的IT设施转化为简单的业务视图，它帮助我们从IT服务的角度出发，保障IT部门提供稳定可靠的服务。
阅读分享：http://www.sootoo.com/content/47944.shtml 

云计算解决方案可让企业快速部署服务以及降低总体拥有成本，这也是为什么首席信息官(CIO)转向软件即服务(SaaS)来提供有效高效服务的原因。
然而，尽管云计算解决方案有很多优势，但企业还必须考虑部署SaaS的安全影响。成功云计算转型的关键是在转移到SaaS解决方案时使用适当的安全控制。
部署SaaS最佳做法
部署SaaS并不会自动保证整体基础设施的安全性，企业应该查看需要保护的服务的安全控制情况。例如，你必须了解针对客户关系管理(CRM)解决方案的攻击的特定后果。同时，你必须确保你的安全信息和事件管理(SIEM)解决方案能够从这个CRM中收集数据。
同样重要的是管理联合身份，因为很多SaaS解决方案要求不同类型的身份验证。强迫用户输入多个密码并不足以构建正确的安全文化。
IT经理通常会基于不现实的战略决策来决定是否部署云计算交付模型。但如果公司决定不允许其员工利用云计算服务，可能为时已晚。云计算服务已经在企业功能中使用，例如很多库使用云端应用程序接口(API)，而员工早就开始使用云应用。
复杂的生态系统
云应用的生命周期必须包含动态安全分析，这些应用是复杂生态系统的一部分。它们可能今天很安全，第二天就布满漏洞，这主要取决于生态系统的状态。
企业应该专注于向服务安装安全控制，确保部署这些控制的技术不会依靠交付模型。否则，你可能会被迫部署不是基于战略决策的技术和业务模型，只是为了挽救以前的投资。为内部部署和云服务提供相同的安全控制是良好安全策略的关键因素。
SaaS提供商的责任
应用是恶意攻击者执行网络攻击的窗口，因此，安全应该成为这些应用开发周期的一部分。SaaS提供商需要不断测试他们的产品，并根据安全响应专家制定的流程和最佳做法对漏洞作出响应。
供应商还应该在非常坚实的基础设施即服务(IaaS)以及平台即服务(PaaS)上提供SaaS，最后，SaaS提供商还必须遵守隐私和数据管理法规。
OTPUB直播活动又双叒叕来喽！

直播主题

Excel的“天上人间”-“出台”到PPT的动态图表

直播时间

2017年4月25日 14:00-15:00

点击参与报名>>>
http://www.otpub.com/special/Excel0425/excel0425_baoming.html

自动代理配置url： https://raw.githubusercontent.com/bannedbook/fanqiang/master/ios/ios.pac

图示:

完美解决:

1、蜻蜓FM 【 http://www.qingting.fm/#/home 】


2、豆瓣FM【 https://douban.fm/ 】


3、多听FM【 http://www.duotin.com/ 】

 
4、考拉FM【 http://www.kaolafm.com/ 】

 
5、荔枝FM【 http://lizhi.fm 】

 
6、喜马拉雅FM【 http://www.ximalaya.com/explore/】

 
7、酷FM【 http://fm.kugou.com】

 
8、企鹅FM【 http://fm.qq.com 】

 
周末放下工作，放空心情。打开手机或者你的APP，选择一个FM电台，用心倾听！还有其他喜欢的可以评论贴出！