天际php技巧_从天际到腾讯10年不苟且的运维之路

从事互联网运维事情已13年，目前就职于腾讯-互动娱乐部，卖力游戏大数据的运营，曾就职于天涯社区，担当首席架构师/系统管理员。

热衷开源技能的研究，包括系统架构、运维开拓、负载均衡、缓存技能、数据库、NOSQL、分布式存储、中间件、大数据及云打算、Mesos、Docker、DevOps等领域。

善于大规模集群的运维事情，尤其在自动化运维方面有着非常丰富的履历。

同时热衷于互联网前沿技能的研究，生动在海内社区、业界技能大会，充当一名开源技能的传播与分享者。

荣获2011年度中国十大精彩IT博客

受邀2012年度中国IT博客大赛评审团评委

开放运维同盟(OOPSA)大数据顾问组成员

2014年度“十大精良讲师”

《python自动化运维：技能与实践》《Docker深入详解》，编写中

最近比较关注大数据、云打算、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管理平台”第一韶光被海内某证卷公司采取，当时觉得很有造诣感。

比较故意思的“做事器机柜仿照图平台”项目，不少公司在此根本上陆续出升级版本，平台截图如下：

可以通过下面网址，访问在线版本

http://blog.liuts.com/idc/

后面也将内部的运维管理平台原型做了开源，同时也在《Python自动化运维实践》书本中做了先容，下面为OMServer平台截图

小履历：

05年开始写博客，当时目的比较纯挚，即当条记本来用，后来逐步演化成互换沟通的平台，收到很多同行的评论、邮件，也认识了很多业界大牛，很多好友到现在还保持联系。

坚持写博客是一件非常困难的事。
但在荣获了2010年度《十大精彩IT博客》的同时，也让我领悟到每写一篇博客实在便是个人对事情、生活的一次总结。
不但可以磨炼你的措辞组织、逻辑思维、表达等能力，还可以给你增加人气，提升个人影响力 ^_^。

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

http://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&AQ1：自行研发tglog对付海量日志传输是否紧张走的udp协议？如果是走的udp协议，怎么去办理一些数据包传输中数据乱序以及数据反序列化问题，或者做了哪些协议层面的优化？

A: 是的，紧张走的是UDP协议。
tglog同时也是一套数据日志的规范，约束开拓职员打日志的标准。

目前未碰到数据乱序以及数据反序列化问题，以前面临一个比较大的问题是丢包情形，尤其在流量高峰期时段更为明显。

后面在内核、IO优化得到缓解，但无法规避，以是我们比拟较主要的日志采取TCP传输。
比如玩家消费流水。

A: 这已经不是运维层面推动的事情，必须升级到运维及开拓的上层领导，开拓任务繁重不是情由，上线后出问题一样得不偿失落，提前抛出风险，让开发职员负责做好上线前的评估。

A: 这块没有统一的标准，看实际业务场景来决定，我们遵照一个原则是：最大化解耦。

其余一个须要考虑的点：是否为原子调度单元。