My Life类日志
导言
最近比较关注大数据、云计算、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: 这块没有统一的标准，看实际业务场景来决定，我们遵循一个原则是：最大化解耦。
另外一个需要考虑的点：是否为原子调度单元。
【IT168 专稿】2012年的春运潮造就了中国铁路客户服务中心12306网络购票系统一夜蹿红，从传统购票方式到电子商务，2012年1月1日开通的12306网络购票系统成为了铁道部改革的重要一步。
但是随着12306系统的上线，各种关于12306系统的抱怨声也层出不穷，不少人抱怨网上订票系统十分“龟速” 网络运行奇慢，网页不时“崩溃”，平均刷新500次才能购到一张票，而且订票过程十分繁琐，从用户注册到支付成功，要13道“工序”，让人晕头转向等等。
本来为了让每个归家的人更方便地买到火车票，而12306网上订票系统这个号称斥数千万元巨资建立的电商的表现却难以让人信服，并引发了一些讨论和思考，应该如何建设类似12306网上订票系统这种大型高并发高性能网站呢?IT168记者采访了腾讯架构平台部刘天斯，对于大型高并发高性能网站的建设和优化，他给出了自己的建议。
12306订票网站存在哪些需求特点和挑战？
12306订票网站具有分时段、分区域、高并发等特点，如何确保在高峰时段正常提供服务是一个非常大的挑战，放眼春运期间网上订票系统，表现为页面访问延时大、登录异常、支付失败等问题。这其中存在一定客观因素，也不排除对流量预估不准确、架构设计不合理等情况。官方公布日均PV达10亿，在高峰时段有千万PV的访问量，应对如此高的流量需要从带宽、服务器、网络、应用及业务逻辑等进行优化。
国内的大型网站还包括淘宝、京东、新浪等，12306的访问模式和淘宝、京东存在哪些异同？
相同点都可以理解成电子商务网站，无论是业务逻辑还是应用特点都非常相似，唯一的差别是12306的流量因时段、区域更为集中，有人说像淘宝、京东搞促销，比如”秒杀”。但”秒杀”的对象往往比较固定，后端可以通过缓存机制或静态化来缓解数据库I/O压力，而12306需要每隔10分钟更新票务信息，同时还要保持与集团其它业务系统对接，这点处理起来更为棘手。
淘宝、TMall、京东也曾经遭遇宕机事件，这些宕机事件和12306网站崩溃有何异同？
此类宕机事件原因都是相似的，无非是宽带吃紧或服务器性能出现瓶颈(应用故障、高I/O或业务逻辑异常等)。差异点只有体现在业务层面上，促销活动可以推迟或重新组织，但12306订票系统不行。反之，12306有其它辅助的补救、缓解方案，如电话预定、代售点等，传统的电子商务平台则没有。
12306订票网站在哪些方面可能存在问题？在以上谈到的问题上是否都有一些相应的优化建议呢？
个人认为更有价值是体现在数据分析上，如得到宽带数据、用户流量、区域分布、请求特点、应用瓶颈点、服务器的性能指标等等，这些数据对优化、改良现有架构非常有帮助。抛开宽带因素，以下是对12306平台系统架构的几点建议：
一、前端优化
具体参考：yahoo前端优化34条规则，针对12306平台，个人建议在没有多运营商链路接入(如BGP)的情况下继续使用CDN进行加速。动、静态应用分离，静态业务使用非12306.cn域名可以减少无用cookie带来的流量。任何一个小细节在高并发下都会被无限放大(截止目前发现平台还是以dynamic.12306.cn域名做静态引用)。查询页面的结果是通过Ajax异步返回填充iframe框架来实现，这对动态CDN加速是一个挑战，因为CDN节点并没有真正缓存页面中主要加速的内容。另外提高验证码的复杂度及多样性，可以缓解刷票机给平台带来的压力。
二、运用缓存
缓存最大的好处是减少后端数据存储的I/O压力，从一个普通用户订票轨迹来看，查询读往往是入库写的好几倍，如何减少数据库的读I/O对提高平台的整体性能至关重要，比较流行的缓存技术有针对页面及数据级，页面级缓存有varnish、squid等，如使用CDN，页面级的缓存可以不用考虑，重点将精力放在数据级的缓存规划上，技术方面可以用Nosql来实现，比较成熟的Nosql有memcached、redis、mongodb等。可以根据班次、出发与目的地ID组合或出发日期进行hash分区，这样可以很好地提高缓存命中率，减少后端数据库的压力。
三、代理层
引入代理层的目的是拆分业务，目前平台绝大部分功能都共用一组WEB服务器(从域名及URI结构猜测，不一定准确)来对外提供服务，比如登录、注册、车票查询、余票查询、列车时刻表查询、正晚点查询、订单管理等等，只要其中一个功能模块出现堵塞，影响必定是全局性的。一个好的方法是优化、规范各业务URI，在代理层实现业务的划分，可用的技术有Haproxy、Nginx等，如将/otsweb/regitNote/映射到注册组WEB服务器，/otsweb/AppQuery/映射到查询组WEB服务器，/otsweb/Pay/映射到支付组WEB服务器等等，如此一来，当查询业务出现延时堵塞时不会影响到用户支付。
四、数据库层
之前接触过一些政府行业的业务，数据库服务器往往都使用一台高端的硬件，比如小型机，在互联网行业，尤其是类似于12306订票系统，这往往是最致命的，理由很简单，在大流量并发下处理能力再强的服务器也吐不出数据，因为受网络I/O、磁盘I/O、业务逻辑等方面的限制，所以必须将数据打散，方案有进行读写分离、分区、分片。主从模式可以很好实现读写分离，大部分数据库都支持这点，除此之外还建议使用分区模式，分区策略可以根据业务特点进行，按地域进行分区是一个好主意，因为每个区域都是一个大分区，还可以从业务层面对它做二级甚至三级的"扩展分区"。需要在细化拆分与运营成本上做好平衡。另外I/O密集的点尽量使用SSD代替。
五、负载均衡层
保障一个业务平台的高可用性，采用负载均衡策略必不可少，即使是提供给CDN的源服务器。目前有商用的F5、NetScaler、Radware等，也有开源的LVS，看成本的投入来选择，此处不详细展开讨论。
六、业务层
此次12306网站瘫痪事件，业务层面有无优化的空间?12306网站平台是铁道集团在互联网上对外服务的窗口，与电话订票、代售点都是平级的，后端肯定还关联着很多复杂的业务系统，在没有对整个集团业务系统做扩容的前提下(短期内估计不能实现)，可以将网站业务平台剥离出来，当然，完全剥离也不太实际，至少可以延长同步、一致性校验的时间。时间的长短随班次的发车时间成正比，因为大部分的用户都是提前一周以上就着手预定车票。
从百万级、到千万级并发PV的网站，在构架和部署方面会存在哪些差异?
百万PV到千万是一个级别的提升，设计得再好的架构也很难一步到位，也是随着业务的高速增长，不断积累经验、优化、改良的过程。12306的流量达到千万PV 级，但平台的支撑能力远远没有达到预期。
一个大型的高并发高性能网站架构需要从哪些层面去考虑?服务器/存储部署方面需要注意哪些问题?哪些技术能够保证整体系统的高并发与高性能?
设计一个大型高并发网站的架构，首先必须以了解业务特点作为出发点,架构的目的是支撑业务，需要考虑互联互通、负载均衡、网络、开发、缓存、存储、数据库等层面，这些层面看似一个整体，任何一个环节出问题都可能导致整个网站崩溃，所以一个高可用、高并发的平台还少不了监控、开发、运维等角色通力协作。
部署大型的高并发高性能网站架构需要注意哪些问题?存在哪些挑战?高峰期和低谷期的资源和投入如何平衡?
部署大型的高并发高性能网站架构需要注意整体的扩展性与健壮性，解决未来海量数据的存储与处理、密集的数据I/O、互联互通、应用的不断迭代、重构以及缓存机制等问题，对于考验一个成功的架构提出了更高的要求，也是未来面临最大的挑战。对于平衡高峰期和低谷期的资源投入，我想云计算的伸缩性更适合解决该问题。
有人建议使用云计算平台(类似于Amazon之类的)来搭建这类网站，以便提高资源利用率节省成本，您是如何看待的?
云计算是未来一个趋势，优点不多说，它具有动态伸缩、灵活性强等特点，可以让资源利用最大化，可以更好节约成本，非常适用于12306平台。
虚拟化(不局限于服务器虚拟化，也可以包括网络虚拟化等)在这类型大型高并发网站建设过程中可以起到什么作用?
虚拟化是云计算的基石，可以降低企业运营成本，提高资源利用率，个人建议将一些运算量及I/O要求不高的业务迁移到虚拟化，比如web、缓存、代理、中间件服务等应用。在低流量时段可以销毁节点，使物理实体机处于低功耗状态下运行，绿色环保，高峰来临时可以迅速部署上线来提供服务。
原文：http://server.it168.com/a2012/0208/1309/000001309060_all.shtml
但是随着12306系统的上线，各种关于12306系统的抱怨声也层出不穷，不少人抱怨网上订票系统十分“龟速” 网络运行奇慢，网页不时“崩溃”，平均刷新500次才能购到一张票，而且订票过程十分繁琐，从用户注册到支付成功，要13道“工序”，让人晕头转向等等。
本来为了让每个归家的人更方便地买到火车票，而12306网上订票系统这个号称斥数千万元巨资建立的电商的表现却难以让人信服，并引发了一些讨论和思考，应该如何建设类似12306网上订票系统这种大型高并发高性能网站呢?IT168记者采访了腾讯架构平台部刘天斯，对于大型高并发高性能网站的建设和优化，他给出了自己的建议。
12306订票网站存在哪些需求特点和挑战？
12306订票网站具有分时段、分区域、高并发等特点，如何确保在高峰时段正常提供服务是一个非常大的挑战，放眼春运期间网上订票系统，表现为页面访问延时大、登录异常、支付失败等问题。这其中存在一定客观因素，也不排除对流量预估不准确、架构设计不合理等情况。官方公布日均PV达10亿，在高峰时段有千万PV的访问量，应对如此高的流量需要从带宽、服务器、网络、应用及业务逻辑等进行优化。
国内的大型网站还包括淘宝、京东、新浪等，12306的访问模式和淘宝、京东存在哪些异同？
相同点都可以理解成电子商务网站，无论是业务逻辑还是应用特点都非常相似，唯一的差别是12306的流量因时段、区域更为集中，有人说像淘宝、京东搞促销，比如”秒杀”。但”秒杀”的对象往往比较固定，后端可以通过缓存机制或静态化来缓解数据库I/O压力，而12306需要每隔10分钟更新票务信息，同时还要保持与集团其它业务系统对接，这点处理起来更为棘手。
淘宝、TMall、京东也曾经遭遇宕机事件，这些宕机事件和12306网站崩溃有何异同？
此类宕机事件原因都是相似的，无非是宽带吃紧或服务器性能出现瓶颈(应用故障、高I/O或业务逻辑异常等)。差异点只有体现在业务层面上，促销活动可以推迟或重新组织，但12306订票系统不行。反之，12306有其它辅助的补救、缓解方案，如电话预定、代售点等，传统的电子商务平台则没有。
12306订票网站在哪些方面可能存在问题？在以上谈到的问题上是否都有一些相应的优化建议呢？
个人认为更有价值是体现在数据分析上，如得到宽带数据、用户流量、区域分布、请求特点、应用瓶颈点、服务器的性能指标等等，这些数据对优化、改良现有架构非常有帮助。抛开宽带因素，以下是对12306平台系统架构的几点建议：
一、前端优化
具体参考：yahoo前端优化34条规则，针对12306平台，个人建议在没有多运营商链路接入(如BGP)的情况下继续使用CDN进行加速。动、静态应用分离，静态业务使用非12306.cn域名可以减少无用cookie带来的流量。任何一个小细节在高并发下都会被无限放大(截止目前发现平台还是以dynamic.12306.cn域名做静态引用)。查询页面的结果是通过Ajax异步返回填充iframe框架来实现，这对动态CDN加速是一个挑战，因为CDN节点并没有真正缓存页面中主要加速的内容。另外提高验证码的复杂度及多样性，可以缓解刷票机给平台带来的压力。
二、运用缓存
缓存最大的好处是减少后端数据存储的I/O压力，从一个普通用户订票轨迹来看，查询读往往是入库写的好几倍，如何减少数据库的读I/O对提高平台的整体性能至关重要，比较流行的缓存技术有针对页面及数据级，页面级缓存有varnish、squid等，如使用CDN，页面级的缓存可以不用考虑，重点将精力放在数据级的缓存规划上，技术方面可以用Nosql来实现，比较成熟的Nosql有memcached、redis、mongodb等。可以根据班次、出发与目的地ID组合或出发日期进行hash分区，这样可以很好地提高缓存命中率，减少后端数据库的压力。
三、代理层
引入代理层的目的是拆分业务，目前平台绝大部分功能都共用一组WEB服务器(从域名及URI结构猜测，不一定准确)来对外提供服务，比如登录、注册、车票查询、余票查询、列车时刻表查询、正晚点查询、订单管理等等，只要其中一个功能模块出现堵塞，影响必定是全局性的。一个好的方法是优化、规范各业务URI，在代理层实现业务的划分，可用的技术有Haproxy、Nginx等，如将/otsweb/regitNote/映射到注册组WEB服务器，/otsweb/AppQuery/映射到查询组WEB服务器，/otsweb/Pay/映射到支付组WEB服务器等等，如此一来，当查询业务出现延时堵塞时不会影响到用户支付。
四、数据库层
之前接触过一些政府行业的业务，数据库服务器往往都使用一台高端的硬件，比如小型机，在互联网行业，尤其是类似于12306订票系统，这往往是最致命的，理由很简单，在大流量并发下处理能力再强的服务器也吐不出数据，因为受网络I/O、磁盘I/O、业务逻辑等方面的限制，所以必须将数据打散，方案有进行读写分离、分区、分片。主从模式可以很好实现读写分离，大部分数据库都支持这点，除此之外还建议使用分区模式，分区策略可以根据业务特点进行，按地域进行分区是一个好主意，因为每个区域都是一个大分区，还可以从业务层面对它做二级甚至三级的"扩展分区"。需要在细化拆分与运营成本上做好平衡。另外I/O密集的点尽量使用SSD代替。
五、负载均衡层
保障一个业务平台的高可用性，采用负载均衡策略必不可少，即使是提供给CDN的源服务器。目前有商用的F5、NetScaler、Radware等，也有开源的LVS，看成本的投入来选择，此处不详细展开讨论。
六、业务层
此次12306网站瘫痪事件，业务层面有无优化的空间?12306网站平台是铁道集团在互联网上对外服务的窗口，与电话订票、代售点都是平级的，后端肯定还关联着很多复杂的业务系统，在没有对整个集团业务系统做扩容的前提下(短期内估计不能实现)，可以将网站业务平台剥离出来，当然，完全剥离也不太实际，至少可以延长同步、一致性校验的时间。时间的长短随班次的发车时间成正比，因为大部分的用户都是提前一周以上就着手预定车票。
从百万级、到千万级并发PV的网站，在构架和部署方面会存在哪些差异?
百万PV到千万是一个级别的提升，设计得再好的架构也很难一步到位，也是随着业务的高速增长，不断积累经验、优化、改良的过程。12306的流量达到千万PV 级，但平台的支撑能力远远没有达到预期。
一个大型的高并发高性能网站架构需要从哪些层面去考虑?服务器/存储部署方面需要注意哪些问题?哪些技术能够保证整体系统的高并发与高性能?
设计一个大型高并发网站的架构，首先必须以了解业务特点作为出发点,架构的目的是支撑业务，需要考虑互联互通、负载均衡、网络、开发、缓存、存储、数据库等层面，这些层面看似一个整体，任何一个环节出问题都可能导致整个网站崩溃，所以一个高可用、高并发的平台还少不了监控、开发、运维等角色通力协作。
部署大型的高并发高性能网站架构需要注意哪些问题?存在哪些挑战?高峰期和低谷期的资源和投入如何平衡?
部署大型的高并发高性能网站架构需要注意整体的扩展性与健壮性，解决未来海量数据的存储与处理、密集的数据I/O、互联互通、应用的不断迭代、重构以及缓存机制等问题，对于考验一个成功的架构提出了更高的要求，也是未来面临最大的挑战。对于平衡高峰期和低谷期的资源投入，我想云计算的伸缩性更适合解决该问题。
有人建议使用云计算平台(类似于Amazon之类的)来搭建这类网站，以便提高资源利用率节省成本，您是如何看待的?
云计算是未来一个趋势，优点不多说，它具有动态伸缩、灵活性强等特点，可以让资源利用最大化，可以更好节约成本，非常适用于12306平台。
虚拟化(不局限于服务器虚拟化，也可以包括网络虚拟化等)在这类型大型高并发网站建设过程中可以起到什么作用?
虚拟化是云计算的基石，可以降低企业运营成本，提高资源利用率，个人建议将一些运算量及I/O要求不高的业务迁移到虚拟化，比如web、缓存、代理、中间件服务等应用。在低流量时段可以销毁节点，使物理实体机处于低功耗状态下运行，绿色环保，高峰来临时可以迅速部署上线来提供服务。
原文：http://server.it168.com/a2012/0208/1309/000001309060_all.shtml
