作者简介：

郭宏泽，现任为胜科技技术总监，高级咨询师，IT解决方案专家。拥有12年IT行业工作经验，其中有8年一线运维经验，4年运维开发经验，曾就职于易车网、电信云计算、跟谁学等公司。开发过日志分析系统、CDN流量计费结算系统，自动化容器管理平台等。精通Linux相关技术及Python、Shell、JavaScript等语言。现任多家大型公司咨询顾问，已帮助IBM、惠普、朗讯等多家跨国公司进行容器化及DevOps转型。

AdminSet开源运维平台创建者，DevOps Master，全球运维大会金牌讲师，高效运维社区核心成员。

Python是一个浩瀚如烟的旷阔领域，有着丰富的应用场景，业务系统、云计算、大数据、人工智能都有Python的身影。

Python是一个易于学习的语言，是一个以简洁实用为宗旨的语言，我在以前的工作中接触过PHP、C#、Java等语言，但当我第一次看到Python的时候，有一种相见恨晚的感觉，心里冒出一句话“就它了”。

Python的兴起是由于云计算时代的来临，当IaaS逐渐成熟、PaaS百花齐放的时代到来时，Python终于迎来了它的黄金时代。

由于入门简单、语法精炼、功能库丰富，Python在计算机领域渐渐成为了一种通用语言，无论是应用、平台还是工具，哪个没有Python的API接口或是SDK呢？这正说明了Python的实力。正因为这些原因，Python在DevOps领域成为一种标准，而且不可替代。

如何选择Python版本

Python目前有两个主流版本，Python 2和Python 3，而且都在维护更新，且这两个版本互不兼容。

Python 2和Python 3的区别

我们先来看看Python 2和Python 3 之间的主要区别，参见下表。更多新特性请参考：https://docs.python.org/3/whatsnew/3.0.html。

从Python社区官方态度来看，官方强烈建议直接学习Python 3，因为Python 2只会维护到2020年。那么看到这儿，可能你会觉得应该直接学习Python 3了，但实际上不是这样，我们必须从Python 2开始。

如果我们对一件事举棋不定，那么最好看看别人是怎么做的，下图是Python各版本在2016年7月和8月的下载量统计图。

通过数据换算（Y轴是指数），Python 2.6和Python 2.7的下载量占比超过90%。数据不会说谎，事实就是当前仍然是Python 2主导的世界，Python 2作为大部分应用和工具的基础，还会在相当长的时间内存在。

为什么会出现这样的情况呢？原因有三：

• 技术的发展是快的，但是在生产中落地是非常缓慢的。

• 如果Python 2就能用，为什么非得升级到Python 3呢。

• Python 3不是所有操作系统的默认解释器，在系统环境中使用Python 3会消耗巨大的成本。

出于实用主义考虑，如果能用螺丝刀解决的问题绝不会用一个电钻来解决。使用Python的人大多数是实用主义者，所以出现了在Python3出现多年以后仍然无法普及的现象。

如何学习Python

Python 2和Python 3还有一种平衡的方法，可以同时兼容两个版本，那就是在Python 2中引用Python的__future__库。__future__库里面包含了Python 3的大多特性。 

从Python 2开始学习，向Python 3演进，使用Python 2.7版本，利用Python 2.7的语法兼容性，尽量使用Python 2版本和Python 3版本都能兼容的语法，这样既保证了在现有系统中的兼容性，又为将来全面向Python 3迁移做好了准备。

事实上Python 2的最新版本Python 2.7和Python 3的差异不超过10%，可以说是比较小的，另外Python 2.7已经尽可能地弥合了Python 2与Python 3之间的差异，做到了尽可能多地兼容Python 3。

比如在Python 2.7中使用print “hello world”和 print(“hello world”) 两者都是可以的，但我们应该使用后者，以便全面向Python 3版本迁移。

最后给出几条学习建议：

• 从Python 2.7开始学习，不要使用Python 2.7以前的版本。

• 了解Python 3弃用的语法和包，在书写代码过程中尽量避免。

• 不要使有Python 3.5之前的Python 3.x版本。

• 尽量多地使用Python 2与Python 3相兼容的语法。

• 熟悉__future__库。

• DevOps工程师应主要使用Python 2.7。

• 业务开发工程师可以直接使用Python 3.5。

开发一个简单的监控平台

监控对运维的重要性

“ 因为你是我的眼，让我看见这世界就在我眼前”，这是一首耳熟能详的歌曲《你是我的眼》。监控，对于运维工程师来说就是眼睛，如果没有监控，运维工作就无从谈起；如果没有监控，运维工程师就成了盲人。

一个良好的监控系统可以快速地发现并定位问题，减少宕机时间，提高故障处理速度，减轻运维工作压力，甚至可以促进家庭和谐。

但是对于这么重要的系统，我发现很多公司都做的都不好：要么监控不到位，很多盲区；要么监控过多，太多无效条目导致报警麻木；要么监控系统五花八门，工具琳琅满目，重复监控，条理不清，等等。

我认为产生这些问题的原因主要有两点。其一，人的问题，是我们的运维工作人员对监控没有深刻的认识，经验不足；其二，工具的问题，没有得心应手的工具，开源、闭源，五花八门，难以统筹高效利用及整合。

以前我们习惯于拿来主义，有问题需要用工具，上网查查别人都在用什么，我也下载一个试一试，差不多就行了。

但是现在时代变了，IaaS、PaaS、SaaS的结构越来越复杂，对于运维工程师说来，必须对监控有深度定制或二次开发的能力才能满足当下的需要。

所以我的建议是，可以考虑自研一套监控系统，这固然有压力，但是一旦成功，收益巨大。俗话说万事开头难，开了头其实就不难。我以自己的经验来说说自写一套监控系统的套路。

服务器端

前端开发主要会用到大量的页面元素，我建议使用目前开源的adminlte，这个前端框架元素非常丰富，页面简洁，比较适合作为监控系统的基础页面框架。

adminlte本身是基于Bootstrap开发的，对于我们将来进行深度页面定制是非常友好的。图表库内置了font awesome和iconic，表单整合了Select2，adminlte几乎能满足你的任何要求。

在图形展示上，建议使用Echarts监控图表（参见下图），它由百度团队开发维护，资料文档非常丰富，在图形质量、异步获取和加载方面都比较成熟，要把它嵌入到系统中，只需要引入一个JavaScript包发即可。

后台开发使用Django，主要是快，无论是Model、FORM、Auth等系统，还是在插件中间件的丰富程度、文档的完善度上，Django都具有绝对优势。通过将平台微服务化，Django本身的速度劣势将被弥补。

在监控数据的设计方面，对资产信息、用户关系等的监控肯定要使MySQL这种关系性数据库，但是对于监控条目的处理就得三思而后行了，我见过很多项目都是把监控条目直接丢到MySQL里，导致后期扩展困难，数据库成了监控平台的巨大瓶颈。

我的方法是将所有监控信息全部写入MongoDB这样的NoSQL数据库，无论是在可扩展性还是性能上，它们都能应对当前海量的监控数据需求。

然后在服务端写一个独立的微服务接口，负责接收客户端上传的监控信息，然后将数据进行处理后插入MongoDB，以供前端进行数据调用，下面代码截图是一个API插入的示例。

这个API通过HTTP Server的方式启动，然后监听客户端的POST数据，接收到数据后以服务器本地时间为基准，打上监控数据的时间戳后存入MongoDB，并以主机名为依据，直接进行分表。

客户端

客户端的开发相对来说比较简单，主要引入了requests 进行HTTP动作的处理，引入了Schedule进行定时上报和计划任务，引入了Psutil进行性能信息采集。

客户端的性能数据主要依靠Psutil采集，Psutil有非常丰富的监控接口，能够轻松实现对CPU、内存、网络、磁盘的监控。

获取磁盘信息的函数截图如下：

通过Psutil提供的接口采集性能信息，然后将结果封装成一个Json数据，使用Requests Post提交到服务器的API接口中去——一次监控过程就完成了。

监控平台的通道也就打开了，以后监控任意条目的套路不过如此。NPM、中间件监控、APM，不都是这样吗？采集数据、上报、存盘并展现。

开发规划

服务端、客户端，数据库和图表展现完成之后，一个简单的监控平台雏形就完成了。这只是一个开始，DevOps的核心思想是持续学习、持续迭代，在这个过程中不断完善。有了平台和架子，我们就可以不断地添砖加瓦。

• 对于硬件监控，可以通过Linux系统命令（比如smartctl、dmidecode等）来获取相关信息。

• 对于NPM、CPU、内存、磁盘、网络和进程，可使用Psutil来完成。

• 对于中间件监控，比如MySQL、Nginx，可以通过命令行或是中间件的监控接口来采集数据。

• 对于某些自定义监控，比如监控某个文件大小、某个目录的文件数、某个文件的属性，可以用Shell来完成。

• 对于APM、应用程序指标、函数调用、响应时间、业务数据等，我们可以通过埋点、API或是JVM嗅探来完成。

• 对于报警系统，可以使用邮件、微信等形式，这个可以根据企业自身的需要来设置，都是十几行代码即可搞定。

如果我们使用开源软件Cacti Zabbix，在实现和整合上都会比较麻烦，很多时候会受制于软件原有的结构，二次开发比较麻烦。

所以，我们何不自己写一个，将所有的控制权都放在自己手上呢？况且又不是特别难，在开发平台的过程中，你的Python技术、软件工程能力都会有很大的提升，你将能够快速实现企业的需求，而不是跑到社区去哭诉“给我加个功能吧”。

Python 开发三十六计：

如果您对其中内容表示质疑，欢迎指出并发表意见，一经采纳，您将成为内测版读者，《DevOps三十六计》在年末的第一批印刷将在第一时间送到您的手中。

想与郭宏泽老师直接交流？请加入 DevOps 三十六计交流群

入群请加微信：gaoxiaoyunweiliuce

关注 DevOps 三十六计公众号

我们将长期发布 DevOps 三十六计完整内容

更多相关文章阅读

用 Python 代码自动抢火车票

携程运维自动化平台，上万服务器变更也可以很轻松

智能运维就是 由 AI 代替运维人员？

看腾讯运维应对“18岁照片全民怀旧”事件的方案，你一定不后悔！

运行无间：阿里巴巴运维保障体系的一种最佳实践

芳华永在！一个老运维的20年奋斗史

饿了么异地双活数据库实战

运维版《成都》，听哭了多少人...

阿里万亿交易量级下的秒级监控

IT 运维的救赎——顺丰运维的理想践行

腾讯 SNG 团队首次系统性披露其运维体系：

第九届GOPS全球运维大会将于2018年4月13日-14日在深圳召开。大会为期2天，侧重方向包括AIOps、运维自动化和 DevOps。

为期两天的大会将涵盖众多先进的技术与理念：

点击阅读原文，进入大会官网