本人于2009年12月迁移至独立BLOG。
1、欢迎光临运维进行时，希望认识更多志向相同的朋友!
2、本站部分资源来源于网络，如有侵权请及时与我联系!
3、强烈建议使用Firefox、Opera、Safari及IE7以上的浏览器访问，以获得最佳浏览质量!
4、请勿发表与中华人民共和国法律、法规相抵触的言论,谢谢合作!
5、本人发布的文章与评论内容仅代表本人观点。
1、欢迎光临运维进行时，希望认识更多志向相同的朋友!
2、本站部分资源来源于网络，如有侵权请及时与我联系!
3、强烈建议使用Firefox、Opera、Safari及IE7以上的浏览器访问，以获得最佳浏览质量!
4、请勿发表与中华人民共和国法律、法规相抵触的言论,谢谢合作!
5、本人发布的文章与评论内容仅代表本人观点。
导言
最近比较关注大数据、云计算、Docker、DevOps等几个方向，一会也简单围绕这几点跟大家做个交流。
聊运维人生这个主题有点大，^_^就先从个人怎么入运维这行说起吧。
人在天涯
2003年毕业后的第一份工作是当php、java程序员，人力紧张时还要兼顾美工设计的工作。
工作中一次偶然的机会看到导师在黑压压的界面中敲入不同指令，第一感觉非常震撼，很COOL，联想到《黑客帝国》电影中的画面，与之前接触到的Windows系统完全不一样，后来才晓得是Redhat9（红帽9）。此时还是一名普通码农。
2005年的10月，进入第二个东家-天涯社区，人生的第一个转折点在此酝酿。
由于赶上了公司快速发展的阶段，接触到了很多开源技术，包括LVS、Squid、Haproxy、MongoDB、Mysql、Cfengine等等，也不断应用在生产环境，取得了非常不错的效果，重点业务的高可用持续保持在99.99%。
如何高效运营？
随之新的问题也陆续出现，包括如何更好整合各类开源组件，发挥其最大效能，另一个是如何高效运营。不可否认，具有开发背景的运维人员有着先天性的优势，可以在不同角色之间进行思考，视野被放大。
事实上在天涯6年就做一件事，即主导并实施天涯社区从Windows技术路线往开源架构改造，驱动这个事情有两原因，一个是运营管理成本、另一个是正版化给企业带来的高额成本（视窗+Sqlserver License）。
改造最大难点是没有可参考及借签的对象，文档资料不全。完全依靠原有人员的技术储备，不断摸索。经过“试错 -> 失败 -> 回滚 -> 再尝试”的过程，个人能力在此期间也得到了一次升华。
对Linux环境下的C++做了深入的研究学习，具备这样的知识对开源软件的架构、分层理解及故障定位有很大的帮助。改造后的天涯新架构在当时比较具有代表性且通用。
架构图如下：
2010年天涯IT管理架构
天涯期间的开源项目
取之开源，同样也回馈开源，以下为个人在天涯期间的开源项目，其中开源后的“LVS管理平台”第一时间被国内某证卷公司采用，当时感觉很有成就感。
比较有意思的“服务器机柜模拟图平台”项目，不少公司在此基础上陆续出升级版本，平台截图如下：
可以通过下面网址，访问在线版本
https://blog.liuts.com/idc/
后面也将内部的运维管理平台原型做了开源，同时也在《Python自动化运维实践》书籍中做了介绍，下面为OMServer平台截图
源码托管在:
http://github.com/yorkoliu/pyauto
小经验：
05年开始写博客，当时目的比较单纯，即当笔记本来用，后来慢慢演变成交流沟通的平台，收到很多同行的评论、邮件，也认识了很多业界大牛，很多好友到现在还保持联系。
坚持写博客是一件非常困难的事。但在荣获了2010年度《十大杰出IT博客》的同时，也让我领悟到每写一篇博客其实就是个人对工作、生活的一次总结。不但可以锻炼你的语言组织、逻辑思维、表达等能力，还可以给你增加人气，提升个人影响力 ^_^。
腾讯CDN运维之旅
2011年加盟腾讯，主要负责了腾讯静态、下载类的CDN运维，截止当前已有400+加速节点（包括静态内容平台、游戏下载平台、UGC加速平台、流媒体平台、动态加速平台等），总带宽突破10Tb，覆盖了腾讯QQ、微信、QQ空间、腾讯视频等业务。
流量调度主要通过GSLB来实现，部分业务基于httpDNS来实现。
腾讯自建CDN除了强大的资源部署外，软实力方面做得非常不错，比如：协议栈优化TCP传输、DiskTank解决小文件读写瓶颈与碎片、链路实时调整等，其中链路实时调整依赖全网拓扑的实时测速的数据作为依据，调整事件是通过调用公司的GSLB接口进行刷新。
调度示意图如下：
What happened?
运维期间碰到最头疼的问题还是小运营商的域名、内容劫持，表现形式为TTL、目标指向、内容劫持等几个方面。
Why?：运营这样做的初衷是什么？
减少运营商LDNS设备的性能负载；
减少运营商跨网结算成本；
嵌入捆绑广告营销策略等。
How?：解决的一些思路，发现问题：
主动：遍历域名在所有运营商LDNS的解析结果，与公司的威权GSLB记录做比较，存在异常的解析可以立马被定位；
被动：产品投拆、网友论坛反馈等渠道。目前还没有彻底解决问题的方案，原因是站在运营商的角度，适当的劫持是合理的，不过可以通过商务去推动解决（局部），关于内容劫持比较好的解决方案就是上HTTPS。
腾讯数据运营大舞台
2013 年至今负责腾讯游戏大数据运营体系的建设，支撑百余款游戏的数据接入、传输、ETL分析、大数据基础平台运维等工作，确保日7000亿条(50T)日志流水传输，以及日均10万次计算任务调度质量。
在IT基础服务方面，利用Docker技术及DevOps理念，对游戏数据应用实施持续交付流程、服务弹性调度的落地，以及开发团队与运维团队融合制度的定制。
数据运营简介
当前腾讯游戏数据传输、存储规模：
游戏大数据服务架构图：
其中存储与计算都采用公司级的数据服务平台-TDW（基于Hadoop+Hive构建），传输采用自研的TDBank平台，类似于开源Flume+Kafka的技术方案。
数据采集采用自研的Tglog方案，更轻量、传输效率更高，支持UDP及TCP版本，两个特点：
耦和度低、标准开放接口、接入成本低；
统一化数据运营标准协议XML、数据本地化容灾。
Tglog简介：
也简单介绍下Tglog日志格式的定义吧，分两部分，一为日志描述，二为实体日志。
下图为日志格式描述文件（XML格式）：
下图为采集原始日志格式（表名|字段值1|字段值2|… …）：
支撑数据应用-iData(腾讯智能化游戏数据分析平台)，提供了游戏生命周期管理，且每个环节都结合了数据挖掘算法，做到精准玩家触达，精细化运营的目的。
运维支撑难点：
如何保障海量游戏日志的采集、传输质量达到99.999% 的SLA标准?
需要从几个维度入手，包括元数据管理、数据地图、数据字典、血缘关系、数据对账、安全审计等。同时要确保与各类数据变更的强联动，感兴趣今后可以展开来讨论哈。
二级数据分析集群我们采用Flume+Spark，调度使用Mesos来实现，同时也结合kubernetes来实现长服务组件的调度，有兴趣今后可展开讨论。
我的DevOps观
Why DevOps?
DevOps是开发者和运维之间的高度协同与融合，这个过程贯穿整个软件开发生命周期，从业务规划到创建、交付再到反馈。
需要注意一点是，不仅仅包括是开发和运维团队，真正的 DevOps 方法需要业务部门、测试人员、企业高管、合作伙伴和供应商等配合完成。
主流观点
为什么要DevOps，国内认同度比较高的几个观点，更多可搜索老王分享过的一些文章。
改善团队协作；
帮助控管风险、成本、减少浪费；
提升软件品质；
提高软件迭代速度。
个人观点
个人更趋向于IBM的诠释，即增强客户体验、提高创新能力、更快实现价值。
建立一种机制，从所交付软件应用的所有利益相关方快速获取反馈，利益相关方包括客户、业务部门、用户、供应商、合作伙伴等等；
目标是减少浪费和返工，并将资源转移给价值更高的活动；
将软件快速、高效和可靠地交付于生产的文化、实践和自动化，快速达成目标，实现价值。
How?
怎么去做DevOps？
调整考核和激励机制；
绑定开发、测试、运维，共同输出价值；
全面自动化，减少人工干预；
开展培训和组织开发活动；
制定新体系结构标准。
持续集成、交付、部署是一个非常好的切入点，DevOps全景图：
So What is it?
Devops就是:
CALMS - Culture（文化）
Automation（自动化）
Lean （Lean[精益]理论，其思想源于消除浪费）
Measurement（量化）包括监控、指标、分析
Sharing（分享）
补充概念
很多人会混淆持续交付(Continuous Delivery)、持续部署(Continuous Deployment)两个概念。
简单说明下，持续交付并不是指软件每一个改动都要尽快的部署到产品环境中，它指的是任何的修改都已证明可以在任何时候实施部署，而持续部署是将所有通过了自动化测试的改动都自动的部署到产品环境里。
DEVOPS最终目标及原则方向：
运维要成为一等公民；
让开发人员完成一切；
谁构建，谁运行。
经验点：
前期的沟通铺垫很重要，一定要了解公司内部利益相关方，包括开发负责人、运维主管、项目主管、产品负责人等的诉求及关注点，尽可能共同捆绑目标及输出价值，不同角色区别只在于分工。
其次是让大老板了解DevOps的收益，且要得到老板的支持，因为DevOps落地是一项长期工作，不可能在短期内看到收益。
量化的指标一定要清晰，且直观易懂，包括业务监控平台、分析报告，同时需要提供至少一种产品或用户反馈的途径，可以是产品官网、在线客服，这对提升平台的品质，直接影响产品口碑。这里直接使用了公司现有的非常完善的基础组件及渠道。
持续集成、交付、部署，我们使用了SVN+Jenkins+Docker+应用商店（镜像）。
第一期自动化部署我们采用了HECD架构实现，第二期计划是与蓝鲸平台打通，通过APP形式来实现从集成至部署的封环，很大程度提高了软件迭代的速度及频率，对提升软件品质及运维服务水平至关重要。
此项工作一定要做好，这也是让相关利益方切身感受变化的关键一环。
小知识
什么是HECD架构：构建一个高可用及自动发现的Docker基础架构-HECD
https://blog.liuts.com/post/242/
从业经验
最后再简单分享个人在运维领域从业的两个小经验：
1、一步一个脚印，切忌一步到位。
关于运维自动化这件事情，几乎所有的IT企业都在做，看似是一件非常好的事情，忽略了前提条件，往往付出更大的代价及运营成本。
之前所提到的前提条件便是运维体系“标准化”、“流程化”、“规范化”的建设，覆盖企业中资源、版本、业务发布、监控、事件管理等环节。有了这些作为基础铺垫，运维自动化的建设才会很顺利实施，达成预期。
自动化程度的高低很大程度是随公司所处不同发展阶段，不断去演变而来，不要想着去复制BAT的架构，一步到位是一个很大的误区。
2、运筹帷幄，主动耦合。
对业务的生命周期进行管理，是运维扮演的角色。
一个产品在规划之初运维人员须第一时间介入参与，根据产品特点，提供业务平台前期架构设计、资源评估等数据。
当产品进入开发阶段，须与开发人员保持密切沟通与互动，提供业务接入、缓存、存储、监控、安全等方面规范，以便在编码阶段更好磨合与对接，避免上线后反复做不必要的版本迭代，也使得开发出来的产品具备更高的可运维性。
待业务上线后，务必定期同步相关运营数据给产品与开发人员侧，为后续优化、改进的工作提供数据支持，这也恰恰能体现运维人员的专业性及团队合作意识。
一个感悟
运维体系中各个环节的工作犹如散落在地上的珠子，每个珠子分别代表事件、资源、监控、安全、自动化、日常工作等。
看似是七零八落的，我们需要利用“流程”这条线将所有的珠子串起来。珠子的前后顺序及间隔由“标准规范”来控制。
这样就形成了一条完整的链子，是一个有机的整体，最后会促使运维工作开展得井井有条。这条链子扣在三个点子上，就是“质量”、“效率”、“成本”。
如何保持竞争力？
很喜欢乔希·维茨金在《学习之道》书中一句名言：追求卓越的关键在于，要坚持充满活力，长期的学习过程，不再满足于原地踏步、平平庸庸。
作为一名优秀的运维工程师，应该将学习成果与日常工作相结合，独立及深入思考发现的问题，善于发现不同问题之间的联系，并把它们升华为方法论，最后再做总结与传承。
我的感悟：不断学习才是保持竞争力的唯一途径，不断思考和总结会成为你潜意识的行为；
我的行动：坚持每天1~2小时的学习时间，从未停止。
那么问题来了：
如学习的动力不源于兴趣或好奇心怎么办？
这里跟大家分享我与团队小伙伴探讨的一个观点：
首先应该静下心好好思考，自己5、10年后想过什么样的生活，可以预见的状态是上有老下有小、背着沉重的房贷、车贷。
如此时再去与一个毕业生竞争同一工作岗位，必然会丧失了所有的优势与竞争力，被行业所淘汰只是时间问题。
因此，想过衣食无忧生活，在职业发展过程中处于不败之地，那么，从现在开始就应该怀着空怀心态，不断打怪升级，使自己变得更加强大。
引用萧帮主一分享主题：“危机前的自我拯救”，没有这个勇气或行动是否考虑该转行了？
如何挖掘专利？
再聊聊运维人员如何写专利，在很多人眼里，写专利是一件非常复杂且很难做到的事情，甚至会认为这是开发人员更擅长的领域。
其实写专利并不像大家想象的那么遥远，只要是一个可以实现的方法或思路就能写成专利。比如运维平台当中的一个功能点、一个快速安全扫描的方法、一项容灾传输的技术、自动化测试案例思路、一种有效服务监控的手段等。这些点子都可以写成一个发明专利。
当然，创新及新颖性非常重要，可以先对比现有的技术实现，突出该发明的优势及亮点，就可以开始写交底书了。
如真的没有一点头绪，大家也可以参考个人写过的一些专利，访问中国专利局网，检索发明人：“刘天斯”
http://www.pss-system.gov.cn/sipopublicsearch/search/searchHome-searchIndex.shtml
一则小广告^_^：
在个人著作《Python自动化运维：技术与最佳实践》中也分享一些运维自动化的实现方法与实践案例，供大家参考。
另一著作《Docker深入详解》预计8月上市，敬请关注！谢谢大家的聆听。
Q&A
Q1：自行研发tglog对于海量日志传输是否主要走的udp协议？如果是走的udp协议，怎么去解决一些数据包传输中数据乱序以及数据反序列化问题，或者做了哪些协议层面的优化？
A: 是的，主要走的是UDP协议。tglog同时也是一套数据日志的规范，约束开发人员打日志的标准。
目前未碰到数据乱序以及数据反序列化问题，以前面临一个比较大的问题是丢包情况，尤其在流量高峰期时段更为明显。
后面在内核、IO优化得到缓解，但无法规避，所以我们对比较重要的日志采用TCP传输。比如玩家消费流水。
Q2：规范化、标准化遇到最大问题是什么？我们遇到就是无法行政干涉开发如何写代码？有什么好的方式去引导规范？尤其是开发有很繁重的开发任务.
A: 这已经不是运维层面推动的事情，必须升级到运维及开发的上层领导，开发任务繁重不是理由，上线后出问题一样得不偿失，提前抛出风险，让开发人员认真做好上线前的评估。
Q3：Docker化应用，是否面临胖容器还是瘦容器问题，即每个容器单进程还是多进程，你们这块是如何使用的？
A: 这块没有统一的标准，看实际业务场景来决定，我们遵循一个原则是：最大化解耦。
另外一个需要考虑的点：是否为原子调度单元。
最近比较关注大数据、云计算、Docker、DevOps等几个方向，一会也简单围绕这几点跟大家做个交流。
聊运维人生这个主题有点大，^_^就先从个人怎么入运维这行说起吧。
人在天涯
2003年毕业后的第一份工作是当php、java程序员，人力紧张时还要兼顾美工设计的工作。
工作中一次偶然的机会看到导师在黑压压的界面中敲入不同指令，第一感觉非常震撼，很COOL，联想到《黑客帝国》电影中的画面，与之前接触到的Windows系统完全不一样，后来才晓得是Redhat9（红帽9）。此时还是一名普通码农。
2005年的10月，进入第二个东家-天涯社区，人生的第一个转折点在此酝酿。
由于赶上了公司快速发展的阶段，接触到了很多开源技术，包括LVS、Squid、Haproxy、MongoDB、Mysql、Cfengine等等，也不断应用在生产环境，取得了非常不错的效果，重点业务的高可用持续保持在99.99%。
如何高效运营？
随之新的问题也陆续出现，包括如何更好整合各类开源组件，发挥其最大效能，另一个是如何高效运营。不可否认，具有开发背景的运维人员有着先天性的优势，可以在不同角色之间进行思考，视野被放大。
事实上在天涯6年就做一件事，即主导并实施天涯社区从Windows技术路线往开源架构改造，驱动这个事情有两原因，一个是运营管理成本、另一个是正版化给企业带来的高额成本（视窗+Sqlserver License）。
改造最大难点是没有可参考及借签的对象，文档资料不全。完全依靠原有人员的技术储备，不断摸索。经过“试错 -> 失败 -> 回滚 -> 再尝试”的过程，个人能力在此期间也得到了一次升华。
对Linux环境下的C++做了深入的研究学习，具备这样的知识对开源软件的架构、分层理解及故障定位有很大的帮助。改造后的天涯新架构在当时比较具有代表性且通用。
架构图如下：
2010年天涯IT管理架构
天涯期间的开源项目
取之开源，同样也回馈开源，以下为个人在天涯期间的开源项目，其中开源后的“LVS管理平台”第一时间被国内某证卷公司采用，当时感觉很有成就感。
比较有意思的“服务器机柜模拟图平台”项目，不少公司在此基础上陆续出升级版本，平台截图如下：
可以通过下面网址，访问在线版本
https://blog.liuts.com/idc/
后面也将内部的运维管理平台原型做了开源，同时也在《Python自动化运维实践》书籍中做了介绍，下面为OMServer平台截图
源码托管在:
http://github.com/yorkoliu/pyauto
小经验：
05年开始写博客，当时目的比较单纯，即当笔记本来用，后来慢慢演变成交流沟通的平台，收到很多同行的评论、邮件，也认识了很多业界大牛，很多好友到现在还保持联系。
坚持写博客是一件非常困难的事。但在荣获了2010年度《十大杰出IT博客》的同时，也让我领悟到每写一篇博客其实就是个人对工作、生活的一次总结。不但可以锻炼你的语言组织、逻辑思维、表达等能力，还可以给你增加人气，提升个人影响力 ^_^。
腾讯CDN运维之旅
2011年加盟腾讯，主要负责了腾讯静态、下载类的CDN运维，截止当前已有400+加速节点（包括静态内容平台、游戏下载平台、UGC加速平台、流媒体平台、动态加速平台等），总带宽突破10Tb，覆盖了腾讯QQ、微信、QQ空间、腾讯视频等业务。
流量调度主要通过GSLB来实现，部分业务基于httpDNS来实现。
腾讯自建CDN除了强大的资源部署外，软实力方面做得非常不错，比如：协议栈优化TCP传输、DiskTank解决小文件读写瓶颈与碎片、链路实时调整等，其中链路实时调整依赖全网拓扑的实时测速的数据作为依据，调整事件是通过调用公司的GSLB接口进行刷新。
调度示意图如下：
What happened?
运维期间碰到最头疼的问题还是小运营商的域名、内容劫持，表现形式为TTL、目标指向、内容劫持等几个方面。
Why?：运营这样做的初衷是什么？
减少运营商LDNS设备的性能负载；
减少运营商跨网结算成本；
嵌入捆绑广告营销策略等。
How?：解决的一些思路，发现问题：
主动：遍历域名在所有运营商LDNS的解析结果，与公司的威权GSLB记录做比较，存在异常的解析可以立马被定位；
被动：产品投拆、网友论坛反馈等渠道。目前还没有彻底解决问题的方案，原因是站在运营商的角度，适当的劫持是合理的，不过可以通过商务去推动解决（局部），关于内容劫持比较好的解决方案就是上HTTPS。
腾讯数据运营大舞台
2013 年至今负责腾讯游戏大数据运营体系的建设，支撑百余款游戏的数据接入、传输、ETL分析、大数据基础平台运维等工作，确保日7000亿条(50T)日志流水传输，以及日均10万次计算任务调度质量。
在IT基础服务方面，利用Docker技术及DevOps理念，对游戏数据应用实施持续交付流程、服务弹性调度的落地，以及开发团队与运维团队融合制度的定制。
数据运营简介
当前腾讯游戏数据传输、存储规模：
游戏大数据服务架构图：
其中存储与计算都采用公司级的数据服务平台-TDW（基于Hadoop+Hive构建），传输采用自研的TDBank平台，类似于开源Flume+Kafka的技术方案。
数据采集采用自研的Tglog方案，更轻量、传输效率更高，支持UDP及TCP版本，两个特点：
耦和度低、标准开放接口、接入成本低；
统一化数据运营标准协议XML、数据本地化容灾。
Tglog简介：
也简单介绍下Tglog日志格式的定义吧，分两部分，一为日志描述，二为实体日志。
下图为日志格式描述文件（XML格式）：
下图为采集原始日志格式（表名|字段值1|字段值2|… …）：
支撑数据应用-iData(腾讯智能化游戏数据分析平台)，提供了游戏生命周期管理，且每个环节都结合了数据挖掘算法，做到精准玩家触达，精细化运营的目的。
运维支撑难点：
如何保障海量游戏日志的采集、传输质量达到99.999% 的SLA标准?
需要从几个维度入手，包括元数据管理、数据地图、数据字典、血缘关系、数据对账、安全审计等。同时要确保与各类数据变更的强联动，感兴趣今后可以展开来讨论哈。
二级数据分析集群我们采用Flume+Spark，调度使用Mesos来实现，同时也结合kubernetes来实现长服务组件的调度，有兴趣今后可展开讨论。
我的DevOps观
Why DevOps?
DevOps是开发者和运维之间的高度协同与融合，这个过程贯穿整个软件开发生命周期，从业务规划到创建、交付再到反馈。
需要注意一点是，不仅仅包括是开发和运维团队，真正的 DevOps 方法需要业务部门、测试人员、企业高管、合作伙伴和供应商等配合完成。
主流观点
为什么要DevOps，国内认同度比较高的几个观点，更多可搜索老王分享过的一些文章。
改善团队协作；
帮助控管风险、成本、减少浪费；
提升软件品质；
提高软件迭代速度。
个人观点
个人更趋向于IBM的诠释，即增强客户体验、提高创新能力、更快实现价值。
建立一种机制，从所交付软件应用的所有利益相关方快速获取反馈，利益相关方包括客户、业务部门、用户、供应商、合作伙伴等等；
目标是减少浪费和返工，并将资源转移给价值更高的活动；
将软件快速、高效和可靠地交付于生产的文化、实践和自动化，快速达成目标，实现价值。
How?
怎么去做DevOps？
调整考核和激励机制；
绑定开发、测试、运维，共同输出价值；
全面自动化，减少人工干预；
开展培训和组织开发活动；
制定新体系结构标准。
持续集成、交付、部署是一个非常好的切入点，DevOps全景图：
So What is it?
Devops就是:
CALMS - Culture（文化）
Automation（自动化）
Lean （Lean[精益]理论，其思想源于消除浪费）
Measurement（量化）包括监控、指标、分析
Sharing（分享）
补充概念
很多人会混淆持续交付(Continuous Delivery)、持续部署(Continuous Deployment)两个概念。
简单说明下，持续交付并不是指软件每一个改动都要尽快的部署到产品环境中，它指的是任何的修改都已证明可以在任何时候实施部署，而持续部署是将所有通过了自动化测试的改动都自动的部署到产品环境里。
DEVOPS最终目标及原则方向：
运维要成为一等公民；
让开发人员完成一切；
谁构建，谁运行。
经验点：
前期的沟通铺垫很重要，一定要了解公司内部利益相关方，包括开发负责人、运维主管、项目主管、产品负责人等的诉求及关注点，尽可能共同捆绑目标及输出价值，不同角色区别只在于分工。
其次是让大老板了解DevOps的收益，且要得到老板的支持，因为DevOps落地是一项长期工作，不可能在短期内看到收益。
量化的指标一定要清晰，且直观易懂，包括业务监控平台、分析报告，同时需要提供至少一种产品或用户反馈的途径，可以是产品官网、在线客服，这对提升平台的品质，直接影响产品口碑。这里直接使用了公司现有的非常完善的基础组件及渠道。
持续集成、交付、部署，我们使用了SVN+Jenkins+Docker+应用商店（镜像）。
第一期自动化部署我们采用了HECD架构实现，第二期计划是与蓝鲸平台打通，通过APP形式来实现从集成至部署的封环，很大程度提高了软件迭代的速度及频率，对提升软件品质及运维服务水平至关重要。
此项工作一定要做好，这也是让相关利益方切身感受变化的关键一环。
小知识
什么是HECD架构：构建一个高可用及自动发现的Docker基础架构-HECD
https://blog.liuts.com/post/242/
从业经验
最后再简单分享个人在运维领域从业的两个小经验：
1、一步一个脚印，切忌一步到位。
关于运维自动化这件事情，几乎所有的IT企业都在做，看似是一件非常好的事情，忽略了前提条件，往往付出更大的代价及运营成本。
之前所提到的前提条件便是运维体系“标准化”、“流程化”、“规范化”的建设，覆盖企业中资源、版本、业务发布、监控、事件管理等环节。有了这些作为基础铺垫，运维自动化的建设才会很顺利实施，达成预期。
自动化程度的高低很大程度是随公司所处不同发展阶段，不断去演变而来，不要想着去复制BAT的架构，一步到位是一个很大的误区。
2、运筹帷幄，主动耦合。
对业务的生命周期进行管理，是运维扮演的角色。
一个产品在规划之初运维人员须第一时间介入参与，根据产品特点，提供业务平台前期架构设计、资源评估等数据。
当产品进入开发阶段，须与开发人员保持密切沟通与互动，提供业务接入、缓存、存储、监控、安全等方面规范，以便在编码阶段更好磨合与对接，避免上线后反复做不必要的版本迭代，也使得开发出来的产品具备更高的可运维性。
待业务上线后，务必定期同步相关运营数据给产品与开发人员侧，为后续优化、改进的工作提供数据支持，这也恰恰能体现运维人员的专业性及团队合作意识。
一个感悟
运维体系中各个环节的工作犹如散落在地上的珠子，每个珠子分别代表事件、资源、监控、安全、自动化、日常工作等。
看似是七零八落的，我们需要利用“流程”这条线将所有的珠子串起来。珠子的前后顺序及间隔由“标准规范”来控制。
这样就形成了一条完整的链子，是一个有机的整体，最后会促使运维工作开展得井井有条。这条链子扣在三个点子上，就是“质量”、“效率”、“成本”。
如何保持竞争力？
很喜欢乔希·维茨金在《学习之道》书中一句名言：追求卓越的关键在于，要坚持充满活力，长期的学习过程，不再满足于原地踏步、平平庸庸。
作为一名优秀的运维工程师，应该将学习成果与日常工作相结合，独立及深入思考发现的问题，善于发现不同问题之间的联系，并把它们升华为方法论，最后再做总结与传承。
我的感悟：不断学习才是保持竞争力的唯一途径，不断思考和总结会成为你潜意识的行为；
我的行动：坚持每天1~2小时的学习时间，从未停止。
那么问题来了：
如学习的动力不源于兴趣或好奇心怎么办？
这里跟大家分享我与团队小伙伴探讨的一个观点：
首先应该静下心好好思考，自己5、10年后想过什么样的生活，可以预见的状态是上有老下有小、背着沉重的房贷、车贷。
如此时再去与一个毕业生竞争同一工作岗位，必然会丧失了所有的优势与竞争力，被行业所淘汰只是时间问题。
因此，想过衣食无忧生活，在职业发展过程中处于不败之地，那么，从现在开始就应该怀着空怀心态，不断打怪升级，使自己变得更加强大。
引用萧帮主一分享主题：“危机前的自我拯救”，没有这个勇气或行动是否考虑该转行了？
如何挖掘专利？
再聊聊运维人员如何写专利，在很多人眼里，写专利是一件非常复杂且很难做到的事情，甚至会认为这是开发人员更擅长的领域。
其实写专利并不像大家想象的那么遥远，只要是一个可以实现的方法或思路就能写成专利。比如运维平台当中的一个功能点、一个快速安全扫描的方法、一项容灾传输的技术、自动化测试案例思路、一种有效服务监控的手段等。这些点子都可以写成一个发明专利。
当然，创新及新颖性非常重要，可以先对比现有的技术实现，突出该发明的优势及亮点，就可以开始写交底书了。
如真的没有一点头绪，大家也可以参考个人写过的一些专利，访问中国专利局网，检索发明人：“刘天斯”
http://www.pss-system.gov.cn/sipopublicsearch/search/searchHome-searchIndex.shtml
一则小广告^_^：
在个人著作《Python自动化运维：技术与最佳实践》中也分享一些运维自动化的实现方法与实践案例，供大家参考。
另一著作《Docker深入详解》预计8月上市，敬请关注！谢谢大家的聆听。
Q&A
Q1：自行研发tglog对于海量日志传输是否主要走的udp协议？如果是走的udp协议，怎么去解决一些数据包传输中数据乱序以及数据反序列化问题，或者做了哪些协议层面的优化？
A: 是的，主要走的是UDP协议。tglog同时也是一套数据日志的规范，约束开发人员打日志的标准。
目前未碰到数据乱序以及数据反序列化问题，以前面临一个比较大的问题是丢包情况，尤其在流量高峰期时段更为明显。
后面在内核、IO优化得到缓解，但无法规避，所以我们对比较重要的日志采用TCP传输。比如玩家消费流水。
Q2：规范化、标准化遇到最大问题是什么？我们遇到就是无法行政干涉开发如何写代码？有什么好的方式去引导规范？尤其是开发有很繁重的开发任务.
A: 这已经不是运维层面推动的事情，必须升级到运维及开发的上层领导，开发任务繁重不是理由，上线后出问题一样得不偿失，提前抛出风险，让开发人员认真做好上线前的评估。
Q3：Docker化应用，是否面临胖容器还是瘦容器问题，即每个容器单进程还是多进程，你们这块是如何使用的？
A: 这块没有统一的标准，看实际业务场景来决定，我们遵循一个原则是：最大化解耦。
另外一个需要考虑的点：是否为原子调度单元。
【当当】 http://product.dangdang.com/23593858.html
【京东】 http://item.jd.com/11571426.html
【亚马逊】 http://www.amazon.cn/%E5%9B%BE%E4%B9%A6/dp/B00P5VKZWW
【天猫】 http://detail.tmall.com/item.htm?spm=a1z10.3.w4011-7555161747.28.SgDdii&id=42141530490&rn=3a7da8b28eea552fb6ebb6ed43ab024d&abbucket=18
【China-pub】 http://product.china-pub.com/3804188
《python自动化运维：技术与最佳实践》附带示例及案例源码
【国内镜像】（JD云汇）https://code.jd.com/yorkoliu/pyauto
【国外镜像】（Github）https://github.com/yorkoliu/pyauto
【源码打包下载】（zip）http://share.weiyun.com/9e4bfc70a9af8840927b92910ab80d8b
一、内容简介
本书在中国运维领域将有“划时代”的重要意义：一方面，这是国内第一本从纵、深和实践角度探讨Python在运维领域应用的著作；一方面本书的作者是中国运维领域的“偶像级”人物，本书是他在天涯社区和腾讯近10年工作经验的结晶。因为作者实战经验丰富，所以能高屋建瓴、直指痛处，围绕Python自动化运维这个主题，不仅详细介绍了系统基础信息、服务监控、数据报表、系统安全等基础模块，而且深入讲解了自动化操作、系统管理、配置管理、集群管理及大数据应用等高级功能。最重要的是，完整重现了4个来自实际生产环境的不同功能运维平台的综合案例，展示了完整的平台架构及开发流程。
全书一共16章：基础篇（1-4章）详细介绍了系统基础信息、业务服务监控、定制业务质量报表、系统安全等基础和常用模块；高级篇（5-12章）深入讲解了批量运维管理器pexpect、paramiko、Fabric，集中化管理平台Ansible、Saltstack，统一网络控制器Func等高级功能，涵盖自动化操作、系统管理、配置管理、集群管理及大数据应用等主题；案例篇（13-16章）详细介绍了4个来自不同平台的运维案例，如何从零开始打造一个B/S自动化运维平台、如何打造Linux系统安全审计功能、如何构建分布式质量监控平台、如何构建桌面版C/S自动化运维平台，这4个案例均来自实际生产环境。
二、目录
前 言
第一部分 基础篇
第1章 系统基础信息模块详解 2
1.1 系统性能信息模块psutil 2
1.1.1 获取系统性能信息 3
1.1.2 系统进程管理方法 6
1.2 实用的IP地址处理模块IPy 7
1.2.1 IP地址、网段的基本处理 8
1.2.2 多网络计算方法详解 9
1.3 DNS处理模块dnspython 11
1.3.1 模块域名解析方法详解 11
1.3.2 常见解析类型示例说明 12
1.3.3 实践：DNS域名轮循业务监控 14
第2章 业务服务监控详解 17
2.1 文件内容差异对比方法 17
2.1.1 示例1：两个字符串的差异对比 17
2.1.2 生成美观的对比HTML格式文档 19
2.1.3 示例2：对比Nginx配置文件差异 19
2.2 文件与目录差异对比方法 21
2.2.1 模块常用方法说明 21
2.2.2 实践：校验源与备份目录差异 25
2.3 发送电子邮件模块smtplib 27
2.3.1 smtplib模块的常用类与方法 27
2.3.2 定制个性化的邮件格式方法 28
2.3.3 定制常用邮件格式示例详解 29
2.4 探测Web服务质量方法 34
2.4.1 模块常用方法说明 35
2.4.2 实践：实现探测Web服务质量 36
第3章 定制业务质量报表详解 39
3.1 数据报表之Excel操作模块 39
3.1.1 模块常用方法说明 41
3.1.2 实践：定制自动化业务流量报表周报 48
3.2 Python与rrdtool的结合模块 50
3.2.1 rrdtool模块常用方法说明 51
3.2.2 实践：实现网卡流量图表绘制 53
3.3 生成动态路由轨迹图 56
3.3.1 模块常用方法说明 56
3.3.2 实践：实现TCP探测目标服务路由轨迹 57
第4章 Python与系统安全 60
4.1 构建集中式的病毒扫描机制 60
4.1.1 模块常用方法说明 61
4.1.2 实践：实现集中式的病毒扫描 61
4.2 实现高效的端口扫描器 64
4.2.1 模块常用方法说明 64
4.2.2 实践：实现高效的端口扫描 66
第二部分 高级篇
第5章 系统批量运维管理器pexpect详解 70
5.1 pexpect的安装 70
5.2 pexpect的核心组件 71
5.2.1 spawn类 71
5.2.2 run函数 74
5.2.3 pxssh类 75
5.3 pexpect应用示例 76
5.3.1 实现一个自动化FTP操作 76
5.3.2 远程文件自动打包并下载 77
第6章 系统批量运维管理器paramiko详解 79
6.1 paramiko的安装 79
6.2 paramiko的核心组件 81
6.2.1 SSHClient类 81
6.2.2 SFTPClient类 82
6.3 paramiko应用示例 85
6.3.1 实现密钥方式登录远程主机 85
6.3.2 实现堡垒机模式下的远程命令执行 85
6.3.3 实现堡垒机模式下的远程文件上传 88
第7章 系统批量运维管理器Fabric详解 91
7.1 Fabric的安装 91
7.2 fab的常用参数 92
7.3 fabfile的编写 93
7.3.1 全局属性设定 93
7.3.2 常用API 94
7.3.3 示例1：查看本地与远程主机信息 95
7.3.4 示例2：动态获取远程目录列表 96
7.3.5 示例3：网关模式文件上传与执行 97
7.4 Fabric应用示例 98
7.4.1 示例1：文件打包、上传与校验 98
7.4.2 示例2：部署LNMP业务服务环境 99
7.4.3 示例3：生产环境代码包发布管理 101
第8章 从“零”开发一个轻量级WebServer 104
8.1 Yorserver介绍 104
8.1.1 功能特点 104
8.1.2 配置文件 105
8.2 功能实现方法 106
8.2.1 HTTP缓存功能 107
8.2.2 HTTP压缩功能 111
8.2.3 HTTP SSL功能 111
8.2.4 目录列表功能 114
8.2.5 动态CGI功能 114
第9章 集中化管理平台Ansible详解 118
9.1 YAML语言 119
9.1.1 块序列描述 120
9.1.2 块映射描述 120
9.2 Ansible的安装 121
9.2.1 业务环境说明 121
9.2.2 安装EPEL 122
9.2.3 安装Ansible 122
9.2.4 Ansible配置及测试 122
9.2.5 配置Linux主机SSH无密码访问 123
9.3 定义主机与组规则 124
9.3.1 定义主机与组 124
9.3.2 定义主机变量 125
9.3.3 定义组变量 125
9.3.4 分离主机与组特定数据 126
9.4 匹配目标 127
9.5 Ansible常用模块及API 127
9.6 playbook介绍 132
9.6.1 定义主机与用户 132
9.6.2 任务列表 133
9.6.3 执行playbook 134
9.7 playbook角色与包含声明 135
9.7.1 包含文件，鼓励复用 135
9.7.2 角色 136
9.8 获取远程主机系统信息：Facts 141
9.9 变量 142
9.9.1 Jinja2过滤器 143
9.9.2 本地Facts 143
9.9.3 注册变量 144
9.10 条件语句 145
9.11 循环 146
9.12 示例讲解 147
第10章 集中化管理平台Saltstack详解 155
10.1 Saltstack的安装 156
10.1.1 业务环境说明 156
10.1.2 安装EPEL 156
10.1.3 安装Saltstack 156
10.1.4 Saltstack防火墙配置 157
10.1.5 更新Saltstack配置及安装校验 157
10.2 利用Saltstack远程执行命令 158
10.3 Saltstack常用模块及API 161
10.4 grains组件 166
10.4.1 grains常用操作命令 167
10.4.2 定义grains数据 167
10.5 pillar组件 170
10.5.1 pillar的定义 171
10.5.2 pillar的使用 173
10.6 state介绍 174
10.6.1 state的定义 174
10.6.2 state的使用 175
10.7 示例：基于Saltstack实现的配置集中化管理 177
10.7.1 环境说明 177
10.7.2 主控端配置说明 177
10.7.3 配置pillar 179
10.7.4 配置state 180
10.7.5 校验结果 183
第11章 统一网络控制器Func详解 185
11.1 Func的安装 186
11.1.1 业务环境说明 186
11.1.2 安装Func 186
11.2 Func常用模块及API 189
11.2.1 选择目标主机 190
11.2.2 常用模块详解 190
11.3 自定义Func模块 194
11.4 非Python API接口支持 198
11.5 Func的Facts支持 199
第12章 Python大数据应用详解 202
12.1 环境说明 202
12.2 Hadoop部署 203
12.3 使用Python编写MapReduce 207
12.3.1 用原生Python编写MapReduce详解 208
12.3.2 用Mrjob框架编写MapReduce详解 212
12.4 实战分析 216
12.4.1 示例场景 216
12.4.2 网站访问流量统计 217
12.4.3 网站HTTP状态码统计 219
12.4.4 网站分钟级请求数统计 220
12.4.5 网站访问来源IP统计 221
12.4.6 网站文件访问统计 222
第三部分 案例篇
第13章 从零开始打造B/S自动化运维平台 226
13.1 平台功能介绍 226
13.2 系统构架设计 227
13.3 数据库结构设计 228
13.3.1 数据库分析 228
13.3.2 数据字典 228
13.3.3 数据库模型 229
13.4 系统环境部署 230
13.4.1 系统环境说明 230
13.4.2 系统平台搭建 230
13.4.3 开发环境优化 233
13.5 系统功能模块设计 235
13.5.1 前端数据加载模块 235
13.5.2 数据传输模块设计 237
13.5.3 平台功能模块扩展 240
第14章 打造Linux系统安全审计功能 245
14.1 平台功能介绍 245
14.2 系统构架设计 246
14.3 数据库结构设计 247
14.3.1 数据库分析 247
14.3.2 数据字典 247
14.4 系统环境部署 248
14.4.1 系统环境说明 248
14.4.2 上报主机配置 248
14.5 服务器端功能设计 252
14.5.1 Django配置 252
14.5.2 功能实现方法 253
第15章 构建分布式质量监控平台 256
15.1 平台功能介绍 256
15.2 系统构架设计 257
15.3 数据库结构设计 258
15.3.1 数据库分析 258
15.3.2 数据字典 258
15.3.3 数据库模型 259
15.4 系统环境部署 260
15.4.1 系统环境说明 260
15.4.2 数据采集角色 260
15.4.3 rrdtool作业 261
15.5 服务器端功能设计 263
15.5.1 Django配置 263
15.5.2 业务增加功能 264
15.5.3 业务报表功能 266
第16章 构建桌面版C/S自动化运维平台 269
16.1 平台功能介绍 269
16.2 系统构架设计 270
16.3 数据库结构设计 271
16.3.1 数据库分析 271
16.3.2 数据字典 272
16.3.3 数据库模型 272
16.4 系统环境部署 273
16.4.1 系统环境说明 273
16.4.2 系统环境搭建 273
16.5 系统功能模块设计 274
16.5.1 用户登录模块 274
16.5.2 系统配置功能 275
16.5.3 服务器分类模块 277
16.5.4 系统升级功能 280
16.5.5 客户端模块编写 284
16.5.6 执行功能模块 287
16.5.7 平台程序发布 289
三、书摘与插画
