印度洋的明珠-斯里兰卡团建

本文目录结构

写在前面

一年一次的公司团建又开始了,我比往年参团要早些去年是9月今年是7月感觉像没过多久一样,其实也是正好内部成了民主团今年目的地就是标题的斯里兰卡,在没去斯里兰卡前我对他了解不是很多甚至成团后我还查了一下他的具体位置,有同事说如果要想看海又想看高山可以选择斯里兰卡也正因为这个我最终选择了斯里兰卡,以下介绍了斯里兰卡5天4晚的行程,整体分为三个部分:

  • 总结
  • 必备物品
  • 具体行程

总结

  1. 衣: 斯里兰卡虽然在热带,但是并没有想象那么热因为是一个岛国面朝大海有温度调节的作用,内陆地势又比较高相对比较凉爽。
  2. 食:很多同学说吃不惯当地食品,我个人觉得还可以当然旅游团也尽量帮我们安排了中餐,我看旅游行程中当地的导游吃的都是鸡肉、咖喱和手抓饭之类的,当然我们也会吃个人觉得适当换口味没有问题但估计如果长期居住在这就会有些不适应了。
  3. 住:整体行程旅店还是非常不错的,都有自己的游泳池和沙滩面朝印度洋非常不错,斯里兰卡是一个岛国,主要经济支柱靠旅游、农产品(茶)和港口贸易等所以旅游的设施如旅馆相对都还可以,但不能与国内旅馆比。
  4. 行:行程不是那么紧,每天早上9点出发,晚上8点到旅店,斯里兰卡如果自己去玩的话很多东西都可以忽略,但个人感觉那个海边火车、佛牙寺还是可以都值得体验一下的剩下的就是观海了因为他面朝印度洋且海浪很大适合冲浪。
  5. 文化:斯里兰卡是一个信仰比重人数较高的国家路上到处都是各种教堂与寺庙,你可以在这里了解当地的文化和背景,我还回来特意了解了一下印度教和佛教的一些区别,刷新了我之前对这里的了解。
  6. 其他:
  • 斯里兰卡属于英联邦的成员,母语是英语但是听起来有些怪,非英音非美音。
  • 去时导游说那里有点像80年代中国让我们做好心理准备,去后感觉确实比较破一些但是当地的那种文化还是非常不错的。
  • 当地人比较好客喜欢和你打招呼,当然有些景区也有人不断的在向你推销一些本地特产,哪里都有好人也有坏人,斯里兰卡总体来说还是比较好的。
  • 因为斯里兰卡人口不是很多,很多地方比较原生态有猴子、蛇和本地的一些动物旅游时还是需要注意别被骚扰到。
  • 感觉斯里兰卡消费有些高,但后来在网上查实际并不应该有那么高,所以和国内一样应该是旅游景点附近的东西相对比较贵,但这里也可以讲价钱
  • 前可以简单做一些攻略,譬如你可以看完我这篇游记,我是去前在网上找了一些游记看了看,另外也在喜马拉雅电台上找了一些斯里兰卡的音频游记听了听还是有一些准备的。

必备物品
多功能转换插头(如下截图多个usb接口很方便)、驱蚊水、防水袋、冰袖、帽子、防晒霜、小背包、雨伞、护照+电子签证、银行卡、数据线、丝巾、牙膏(当地旅店不提供)、纸巾和拖鞋等,其他物品根据自己情况而定。


Read More

宝岛台湾团建

本文目录结构

磨磨蹭蹭终于写了个大框 台湾 游记(行程时间:2017.9.19-9.24),整个感觉 台湾 值得一去,以下是一些小体会:

  1. 台湾 旅游比较成熟不会出现宰客现象,旅游设施也比较齐全。
    2.消费感觉略高于 深圳 的平均水平,一顿饭大约在30元左右。去大的餐馆是有服务费的大约是整个餐费10%。
    3.景色宜人,特别是海边。
  2. 台湾 经济感觉有些萧条,虽然平均GDP还高于大陆但感觉不可持续,希望能早日回归。
    5.去 台湾 故宫有人说比较枯燥,但我比较喜欢,去时还要做好攻略,因为每一个藏品都有他悠久的历史和藏在它身上的故事,所以要提前做攻略。
    6.貌似 台湾 除了水果也没什么特产,像凤梨酥比较有名,但是和国内去 厦门 吃也没什么区别,还比较贵。
    以下这张图是iphone里在 台湾 每个地区拍的照片汇总截图:

###################################################################

整体行程

Day1 深圳 -> 香港 -> 台南 -> 垦丁
Day2 垦丁
Day3 垦丁 -> 宜兰
Day4 宜兰 -> 台北
Day5 台北
Day6 台北 -> 香港 -> 深圳
6天行程中从 台湾 的最西南到 台北 的东南,基本玩边了半个 台湾 。 那我从第一天行程开始介绍,整个旅游过程。
###################################################################

Read More

Docker3.0项目总结

开篇

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

如何开发一个项目

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

打造Facebook Docker项目
描绘远景,设置目标; 描绘远景,设置目标;
收集想法并排出优先级; 收集想法并排出优先级
跨团队沟通 跨团队沟通
告诉所有可能关心的人 设计产品
设计产品 指定责任人
指定责任人 定期碰头
定期碰头 了解进度,汇总报告
了解进度,汇总报告 发布产品监控数据
发布产品监控数据

描绘远景,设立目标

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

Docker项目流程图

Read More

Docker2.0项目总结

开篇

腾讯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

Docker1.0 项目

背景

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

负载调度演示(图1)

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

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

Read More

Clip 自动化运维工具

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当天有多少子命令。

代码地址