<<互联网敏捷DevOps和自动化之4.运维自动化>>

<<互联网敏捷DevOps和自动化之4.运维自动化>>

随着信息时代突飞猛进般的持续发展，IT运维已经成为IT服务中最重要的组成部分。近年来，云计算、大数据等技术日趋成熟，生产应用自动化运维也被推到了风口浪尖。通过传统手段对大型计算机集群进行运维即使是简单的日常备份、服务器状态监控和报警，效率也十分低下，因此对自动化运维的需求已经迫在眉睫。
传统运维的弊端：
1.由人来发起运维事件，运维人员被动、效率低。
2.系统异构性大，缺乏高效的运维流程。
3.随着云计算大数据的爆发带来更大的困难，极度缺乏一套高效的运维工具。
由于这些问题的存在，自动化应该遵循四化原则：管理体系化、工作流程化、人员专业化、任务自动化。
以监控作为自动化运维的核心概念
运维工作效率不高，主要原因是响应速度。由于大量的人员长期盯着报警页面，等待故障，然后通知相应人员。所以在生产系统中，需将服务器的状态监控作为自动化运维的核心问题。下图为自动化运维平台处理流程图，由监控来驱动运维事件的发起、处理和结束，由ElkStack 、Zabbix 和 Zabbix-Agent来获取到服务器的日常工作状态和服务信息，并生成时序统计图等用于成果分析。

互联网公司的运维部署架构 基本都是以下模式

image.png

结合现在云计算和DevOps的发展趋势，我觉得一个成熟的自动化运维平台应该包括以下的特性：一、支持混合云的CMDB现在越来越多的服务器都转到了云上，而主流的公有云、私有云平台都拥有比较完备的资源管理的API，这些API也就是构建一个自动化CMDB的基础。新一代的自动化运维平台应该是可以基于这些API来自动维护和管理相关的服务器、存储、网络、负载均衡的资源的。通过API对资源的操作都应该被作为操作日志记录下来，以备作为后续操作审计的基础数据。
CMDB这个东西听上去是老生常谈，但这个确实是所有运维工具的基础设施。而基于开源工具做运维平台最大的麻烦，就是如何在各个工具之间把CMDB统一起来。CMDB不统一起来，就意味着一旦要增加一台服务器，可能要在各个运维工具里面都要同步一下，这个还是非常折腾滴。。。
二、比较完备的监控+应用性能分析（APM）能支持对平台的可用性、服务器的性能、各种服务（web服务、应用服务、数据库服务）的性能进行监控。做的好一些应该能进行更深入、或者关联性的性能分析。
现在市面上一般都会将资源性能监控和应用性能监控（APM）混合着讲，这里面的产品确实也有很多都是重叠的，两方面都会涉及到。
开源的性能监控系统主流有的Zabbix、Nagios，国产的开源监控平台有小米OpenFalcon，但这些基本都只是做基本的资源监控（服务器，磁盘、网络等）和简单的服务软件的性能监控（中间件，数据库等）。
而市面上的APM系统更主打的功能是应用性能分析，比如能精确定位到某个应用的URL的访问速度快慢，某些SQL执行速度的快慢，这些对于开发人员和运维人员快速定位问题还是很有帮助的。APM这方面的商业工具，国外比较主流的有New Reclic、Dynatrace，国内的也就是透视宝、Oneapm、听云等，他们也提供了API进行集成。APM这方面的开源工具有pinpoint（一个韩国团队开源的），zipkin（twitter开源），cat（大众点评开源）。
三、有一个还不错UI的批量运维工具在业务发展比较快的情况下，从几台服务器，到几十台服务器，再到几百台服务器，批量运维的需求很自然就产生了，老板也希望越少的人干越多的活。
现在也有不少开源的批量运维工具，也都比较成熟了，比如puppet、chef、ansible、saltstack。puppet和chef都是ruby做的，实话实说，ruby的熟手市面上很少，比python不是难招一点。
我个人比较推荐使用ansible或者saltstack，这两个系统都是python写的，代码质量和社区活跃度都挺不错的。ansible有官方的web ui——Tower，但实话实说不好用，所以我们也在重新做一套自己用起来更顺手的WEB UI。
四、日志集中分析工具线上系统最常规的问题定位方式，就是日志分析了。随着服务器的增多，日志的分析定位也成为一个难点和痛点（想象一下，系统出故障之后，要去几十甚至数百个节点去上去查日志，是有多折腾）。
国内有一家叫日志易的公司，是专门做日志分析方面的运维工具的。另外还有一家log insight，也是做这个领域，但产品好像还处于beta阶段。
日志分析这个领域现在是一个热点，现在的开源方案也比较多了，比如著名的ELKStack，还有Flume+Kafka+Storm的体系。上面这两个方案相对重一些，部署比较复杂，网上介绍的文章也不少。
比较轻量级的开源日志集中采集方案有python做的Sentry，他是通过改造各种语言的日志采集框架来实现日志的集中采集，各种主流的开发语言的日志框架都支持得很完整了，比如java的log4j和logpack。Sentry的官网在此：Sentry - Track exceptions with modern error logging for JavaScript, Python, Ruby, Java, and Node.js**
五、持续集成和发布工具这方面其实比较难有统一的需求，很多公司集成发布的做法都差异挺大的。持续集成方面，一般用jekins的比较多，这方面网上介绍的文章也很多。
而如何把打好的包发布至各台服务器，则可以通过批量运维工具或者脚本来完成了。版本发布的过程涉及到很多细节，包括了版本文件的上传、分发、版本管理、回滚等各种操作。对于一般不太复杂的项目，我比较推荐的做法是把打包好的文件上传到svn上，然后通过脚本在各台服务器上进行发布操作就行了，这样其实是利用了SVN来完成文件的上传、分发、版本管理、回滚等各种操作。
六、安全漏洞扫描工具现在一个稍微有点知名度的系统，都会遭受各种各样的安全攻击的折磨。一般的公司不太可能请得起专职的安全工程师，所以运维工程师最好能自己借助一些安全扫描工具来发现自己系统的漏洞。安全工具方面我了解不多，不太熟这个领域的开源工具。
Git Web Portal URL address --->
GOGS http://www.jianshu.com/p/424627516ef6 https://gogs.io/

image.png

image.png

image.png

image.png

image.png

GITLAB https://about.gitlab.com/gitlab-com/

image.png