开篇

我们在2015年中的时候就在做Docker1.0（琥珀），当时主要针对离线场景到2016年初琥珀已经小有规模同时也解决了很多生产环境的问题得到大家认可。在2016年3月份中心内部开始讨论要做在线Docker版本，而这只是需求并不是目标，所以我们当时针对中间层（spp）业务进行了调研，设定了目标做业务的弹性伸缩，主要是通过Docker来解决资源的快速扭转，大家用机器时可以更方便拿到，另一方面是减少人为参与上下线，将有限的人力放到更重要的位置让大家能快速成长与学习。
围绕这一小目标， 从2016.3.31发出一封Docker邮件到目前已经有一年多了，内部经历了多次的PK，从技术选型、是否使用开源、人力的配备、项目的优先级等，外部也遭到很多的质疑，为什么搞了这么久没有上量，Docker搞了那么多版本有什么意义、Docker的长期目标是什么，是否可以保持现有体验等等。总感觉项目走在十字路口，选每条路都是对的，但每一条路都未必捷径，总是被挑战中，这里我承认有一点根本原因是，理想很丰满，现实很骨感，我们在谈理想时嘴上总挂着我们要把我们的运营系统往前在走一小步，多么美丽的理想，而落地到现实时，我们需要更多的时间、需要人力、需要每个人情怀、需要顶住外界压力、寻找更多合作团队一起努力才能达到目标。而这并非易事，本邮件主要总结我们在运作项目中遇到的问题、我们的思路、大家对项目的疑问等。

如何开发一个项目

因为我个人并不是专业的项目经理，所以项目开发的过程也是我学习的过程也在思考如何能把整个项目能做的更好能尽快达到短期小目标。前期我参考了软件工程的方法论需求分析、概要设计、详细设计、测试、维护和用户手册等，但感觉并不十分实用于互联网的项目管理，譬如详细设计基本拿到文档就可以开发写程序，而目前我们还做不到这样的详细设计。后期我参考了《打造Facebook》一书其中的一章个人感觉还是比较试用的，但再原有的基础上我也补充了一下本项目开发过程中的案例。

描绘远景，设立目标

开篇中提到要寻找更多的合作伙伴才能达到目标，所以项目建立之初一定要描绘远景、建立短期、中期和长期目标，这样在不同的时间需要伙伴与切入点才一幕了然。以下使我们项目的一个基本项目流程图

Docker项目流程图

Read More

开篇

腾讯SNG（社交网络事业群，后简称“SNG”）事业群担负着QQ、Qzone、QQ音乐和相册等核心社交产品运营，从运营的这些产品就能看出部门的历史。笔者没有进入腾讯前在北京工作过多年，记得在2010左右北京的各种IT大会风起云涌当时可以看到各大公司分享自己的架构与运维理念但很少能看见腾讯的分享，当时很纳闷为什么看不到腾讯分享，多年后走进腾讯当年很多疑惑慢慢揭开了神秘的面纱。

从架构层级上腾讯和很多公司相同即接入、逻辑和存储但腾讯BG(Bussiness Group 事业群，后简称“BG”)制，外人可以理解BG为腾讯内部子公司，彼此有独立的方向、业务与架构，不同的BG架构不同（接入、逻辑和存储）， 与其他公司不同的是，腾讯在各BG架构上又多了一层“大存储”即（接入、逻辑、存储（短期）、存储（长期） ），这里大存储指各BG数据最终落到统一的BG下，即TEG(技术工程事业群)。以SNG为例接入使用qzhttp（web服务）逻辑之间调用关系用了l5（名字服务），程序开发有spp框架， 数据间传输使用了私有协议，存储使用了MySQL和一些自研的数据存储，可以看到腾讯这里走出了一条有自己特色的道路，它更多使用的是自研组件和私有协议，这也就解释了之前笔者的疑惑为什么很少看见腾讯的分享原因。相比很多公司使用开源组建在基础上做二次开发，但腾讯更多是学习开源组建再开发，区别是后者配置文件些许区别维护学习上有一定成本，但优势更加适合业务使用，足够的轻量级和安全，但问题是业务的需求量有限很多自研组建放慢迭代脚步，甚至停滞迭代。

那为什么腾讯内部的工具不走开源路线呢？ 开源接受的市场更多的需求，需要持续的打磨与迭代， 这问题也是笔者在入职腾讯后一直的疑惑 直到一次公司技术分享A同事的一个问题，A同事大概问的意思是腾讯现在在互联网行业内有一定的影响力与同等公司相比开源做的并不是很好，这是为什么？ 当时公司CTO(首席技术官，英文Chief Technology Officer，即企业内负责技术的最高负责人)张志东是这样回答的。首先对A同事问题的肯定，也介绍了这里的背景，早年腾讯业务爆发式增长工程师更多的精力是应对需求以及当业务发生故障时去救火，再者考虑的就是开源软件对数据安全的问题，如果本身能力未达到应用开源软件后遇到风险不能快速解决结果是致命性的。 这两点笔者身有体会特别是随着互联快速发展，网络安全很重要往各种暴库（csdn 索尼）等事件，做过一个公司的CTO需要更加关注用户数据的安全，这也是我们公司的底线用户安全置上。但Tony也说随着腾讯各个业务步入正轨我们也逐渐考虑去做一开源的工作，鼓励各BG开源。老板的一句话给我们带来更多的思考是如何去开源？ 而开源的前题也是如何更好的使用开源的工具在基础上有机会再开源，所以当时笔者也在想自己的业务上去寻找一些场景适合开源工具的解决方案。

Read More

今年参加了公司的肇庆团建（2016.7.25-2016-7.28）4天3夜与以往不同是纯休闲团所以能写的也不是很多，整片文章围绕以下三个方面来介绍：

• 行程与景色
• 住宿与饮食
• 民俗文化与整体感受

Read More

背景

由于历史的原因我们的机器目前还是单机或单集群对应一个业务模块的形式，优势应对爆发式增长扩容方便，成本结算简单。但是随着网民的饱和，相同业务模块下移动流量上涨，PC流量直线下降，很多业务出现了低负载情况，海量服务器运维中只要有1%的低负载（既机器利用率不饱和）规模也是惊人的，在实际运营中低负载+长尾模块机器数量可能达到了25%-30%之间，当然这里也包含业务对流量做了冗余与灾备，但是多个业务模块的灾备就会出现浪费资源的情况。我们从运营中发现了这问题的存在，而运维的核心价值也是通过技术优化，能在（成本、质量、效率与安全）四块做优化达到一个很好的收益，所以从2014年中我们开始做离线业务部署项目。项目的思路是通过高负载业务（离线计算）与低负载业务进行混合部署，提升低负载机器利用率同时逐步下线高负载业务的机器为部门节约机器成本。不过经过半年多的运营中我们也发现了很多问题，离线业务的负载均衡权重统一，但是混合部署后的机器负载不均有高有低，混部的结果经常会导致部分机器高负载影响业务，可以看出这里缺少监控负载的和业务合理的手段，经常导致高负载业务影响低负载业务，接口超时影响用户的情况，这是我们不希望看到的，所以总结经验教训，在2015年上半年我们重新打磨项目开发了离线业务混合部署（琥珀自动调度系统）项目，新项目与老项目相比通过docker技术将混部业务控制在容器中，消除争抢资源对业务影响，同时对容器流量进行根据负载调度，在此基础上实现了分时调度等功能。

负载调度演示（图1）

希望通过技术架构优化与升级来充分扎干硬件资源，为公司节约服务器成本。在开发过程中，相关业务也向我们提出了以下需求（已经实现功能见图2）：

• 机器主动与被动下线不影响在线业务；
• 可以方便的查看到系统运行状态；
• 可以连接到容器内部查询日志以及debug程序；
• 沉淀各系统日常数据，并根据沉淀的数据进行戳峰调度。

Read More

Clip是一款自动化运维工具，适用于海量服务器的管理场景，可以降低系统误操作风险，提高工作效率，工具借鉴了DNS的思路，将传统的IP管理纬度替换为String管理纬度，管理方式的改变使海量运维时更加的便捷、可靠与高效。Clip是C/S架构，它将IP关系保存在Server端，Client端可以下载SDK，通过SDK遍历Server端的IP与模块对应关系，并在本地重新组织与编排，在此基础上工具还扩展了，如远程命令、文件拷贝、IP组织树遍历、历史命令查看、IP对应String关系正反解析与导入等功能，以下是两张应用截图。

字符界面

图形界面

设计思路

首先，传统服务器管理方式与String管理方式的相比，String管理方式的3点优势：

• 见名知意：传统为IP管理方式，IP由4组无意义的数字组成，比较难记忆，与传统方式相比String可以见名识意，方便记忆；
• 防止误操作：管理海量服务时，IP相似经常会导致运营故障，譬如A模块（10.131.24.37 ）和B模块（10.117.24.37） ,后两位数字一致，惯性的认为两个B模块就是A模块，发送配置导致线上故障。通过string管理方式可以很方便的规避此问题；
• 关系正反查：String 可以解析1个IP，也可以解析一组IP ,根据IP也可以反解析String对应关系，这让我们管理一组服务更加的方便。

案例1
String由（idc-product-modules-group） 4段组成，了解cmdb的同学会发现它与cmdb的结构很像，4级模块定位一个服务，但是随着业务的发展，笔者觉得4级服务已经无法定位到一个服务，譬如，在一台服务器上混合部署不同的业务模块，这里4级只能定位到服务的IP级别，而无法精确定位到真正的服务，所以Clip在此基础上增加了一级（idc-product-modules-group-port），port端口，通过5段定位一个服务，相比CMDB这也是Clip优势，灵活变换来定位一组服务。
案例2
上海机房，A模块使用80端口提供服务，目前有100多个机器 ，B模块使用8080端口提供服务，目前有100多个机器，由于业务流量下降，为了节约资源目前想将两个模块200台机器资源合并，但功能不合并 。我们可将两个服务表示到不通的String中，如A模块（sh-weixin-friend-a-80）, B模块（sh-weixin-friend-b-8080），通过String就很容易的将两个服务分别开，并部署在相同的服务器上提供服务了。以下是真实线上应用效果图

扩展命令

目前SDK共有8个子命令：

• scan:用于对String对应的IP进行端口存活状态扫描；
• cstring: 用于对String对应IP解析，与IP对应String关系的解析；
• ssh:用于对String对应IP，远程执行系统命令；
• scp：用于对String对应IP，远程拷贝文件；
• tree: 遍历String下的子节点；
• history:显示历史执行过的命令；
• import: 导入IP对应String关系；
• lt: 从本地获取IP关系进行管理；
• help: 显示Clip当天有多少子命令。

代码地址

• Server端(2019年时用golang重写的,原来是用PHP实现)，地址见:https://github.com/puppeter?tab=repositories
• Client端,用Python实现，地址见：https://github.com/puppeter/clip

来介绍一下《Puppet权威指南》写作过程。做很多事情都需要一个流程，想必大家这里身有体会，譬如一个好的运维体系，基础化、模块化、平台化、自动化和数据挖掘等，少一环节都有可能会影响产品的快速发展。写书也一样，所以这里我差了一个环节，在宣传书的同时分享写书过程与过程中的收益，希望通过介绍整个过程，能让更多朋友为业界提供更多思路与创新技术。

开篇

本文目录结构

• 如何萌生写书想法
• 写书的流程
• 如何将过程转化为收益

如何萌生写书想法

回忆了一下，首先从来没想要写书，只是偶然的机会而已。在2001年左右，上高中时很喜Photoshop和3Dmax，在那时我就已经会安装Windows 98操作系统，在班级中公认的是一个计算机高手。另外，我也经常买《电脑报》、《网友世界》和《黑客X档案》杂志，通过XCAN来扫描远程服务器开放端口，并根据扫描后端口确认是否有漏洞，这些对于那时的我会带来很多的成就感与自豪感，记忆中曾多次一条命令就可以让网吧远程的系统蓝屏，但有一次在网上遇到了牛人，他能随意改我的QQ密码，盗取我的163账号，查IP地址能定位到我的家门牌号，那一刻我觉得自己弱爆了，后来经常与他交流学习经验，那时我最不喜欢学习编程语言，而他说你要做为一个优秀的黑客就要去学习编程语言和网络协议，也是那时他让我第一次知道TCP/IP协议的三卷书，通过与他交流与指导，我开始自学C编程语言，学了才知道C语言并没有想象中那么难。

后来上了大学，操作系统中学了Linux，了解他历史的都应该知道玩Linux才是真正的黑客，所以那时去电脑市场买了一个Redhat6.0版本的系统盘来安装，安装后不知道怎么用，在网上查资料时知道了www.chinaunx.net （简称CU），那年是2006年，因为我的CU ID（研究僧）注册时间就是2006年。从CU学到了很多东西，譬如记忆深刻的《门户网站运维abc》、《Shell能力测试》和《Shell基础20篇》等都是很好的学习资料, 还有一篇文章来描述如何学习Linux，大概中心是要想学好Linux；

• 多看书；
• 多实践；
• 多总结沉淀；
• 遇到问题自己查找资料解决，解决不了再寻求帮助；
• 如果学习的知识点都掌握了，多去帮助他人解决问题，其实帮助他人也是自己学习的一个过程。

所以，在CU经常找别人问的问题，看是否能解决，如果解决不了再去网上找解决思路与过程，那时也是因为这原因，我写了很多文档，由于看了Shell编程13问的文章，忽然觉得我的文档总结可以写成一本书的形式与别的朋友进行分享，经过对文档总结提炼与打磨，最终在2008年写出了第一版本，不过现在已经找不到最初的版本了，在电脑里找到了2010年最后变更时间的书，无意间人生的第一本书就这样的写完了。

2008年在北京工作后，一天在QQ忽然有人问我，看你CU比较活跃是否可以可以来我们这里帮讲一些网络的课程，我抱着试试看的态度应邀去了华章的编辑社，去了才知道这是有名的机械工业出版社，我很喜欢买他们书。到了后是一位美女来接我，交谈中我说我写过书，美女说是否可以发我看看，几天后我提交了一份书的原本发给编辑社，美女帮我指定了出版策划（杨福川），第一次与福川见面时在中关村的麦当劳，感觉一见如故与技术人交谈很开心，他看过我给的文档后，给了我很多出书的建议，说对于刚出茅庐的我书的内容还是很好的，但对于出版来说要走的路还要很多，不过也鼓励我，希望有机会能合作出一本书。就这样几年过去了，应该是2012年系统架构师大会，再次遇见福川，福川问是否有兴趣来写书，我说OK没问题，正好由于内部部门产品变动，我负责的系统没有运营工具，我对Puppet进行研究并在线上应用。那时Puppet知道人并不是很多，所以一拍即合开始写人生的第二本书《Puppet权威指南》。

写书的流程

下定决心后写书并不复杂，以下为写书流程：
1）寻找一个靠谱出版社，因为他会有渠道帮你做后续推广；
2）确认写书的标题与大纲，其中大纲很重要，有一个目标才好量化时间与写作进度。写作大纲中一般还包含选题思路、读者对象、内容简介、市场分析、卖点分析、作者简介和营销建议这7项；
3）签约合同，合同是双方利益保障，对于出书者来说写完出版社不出版，可以通过合同来约束。当然，反过来没按照预定写出来，还是要陪违约金的（这也是签约后动力之一）。除此之外，还要确认付款方式，两种：

• 方式1：一次性买断书的版权，即一次打完所有歀。
• 方式2：是按出版发行量计费，根据书的售卖情况打款（注：我签约的这种）
  大家可以自己来确定付款方式（写书并不挣钱，但是收益还是有很多的，一会会介绍）。
  4）合同确认后，策划会分配一个编辑给作者。我的编辑（孙海亮）海亮给我的感觉三个词形容，积极、专业和耐心。编辑会把控整体的进度、写作风格、语句是否通顺、是否能很好的读者学习了解书中的专业知识内容，然后就是定期发文稿给编辑；
  5）最终出版社收到完整的书稿（齐、清、定）后会制定编辑加工计划，并以书的形式打印出来各章，确认排版与最终效果是否一致，前后有三次校对过程；
  6）最后确定封面，出版与推广；
  7）根据约定出版社付稿酬。

Read More

如何让history不记住你的执行记录，我们来看一下流程。

1. 通过history 命令查看命令列表

2. 执行uptime ，然后通过history 查看记录

3. 通过history 可以查看到刚执行的uptime记录,下面让history 不记录执行的命令，如何操作呢。通过 ls命令前边加空格再次执行。

4. 再次查看history记录,！！没有看到刚执行过的ls命令记录（欺骗成功）。

5. 如果执行的命令前边加空格，默认history命令是不会记录历史的，如何才能让history命令记录加空格的命令呢？ 我们可以修改系统的HISTONTROL环境变量来实现，详细看以下。

默认值

1
2
3
4

HISTONTROL=ignoreboth 
改为
HISTCONTROL=ignoredups
再次执行空格加命令