维护 github enterprise 版本

作为高富帅的公司,我们毫不手软的购买了 github 的 enterprise 版本,截止到 3 月底,我们累计的投入已经接近 6 位数的 $$$ 了。我作为维护者,从管理的角度说说使用的感受。总的来说,四个字 – 「物超所值」。如果你们公司的工程师在 500 人以下,不妨试试,码农们的心情绝对会因为使用这么好的产品而屁颠的合不拢嘴,间接的提高的生产效率,最终受益的还是公司。
目前这种 "out of box" 的产品越来越多,github 是一个典型,包括我之前提到的 elasticsearch 同样是一个典型(github enterprise 重度依赖 es)。好处不必多说,维护起来工作量会小的多,你没有必要也不大可能了解到产品内部的运行的机制,这个从 github 提供的 ssh 登录账号就能看出:
To preserve the integrity of the appliance and ensure it remains in a consistent state, we have the following limitations in place:

    Root access is not provided.
    The admin user password is not provided.
    Installation and execution of third party software is not permitted.
    Modification of the underlying VM configuration is not permitted.

Bypassing any of these limitations will void all warranties and may place your installation in an unsupportable state.

拿到一个新的产品服务,我第一要做的就是先通读遍官方的文档,初次打开,觉得不可思议,一共就几十篇文档,两三个小时就能过完。回头再看的时候发现,对于这么一个 out of box 的产品,几十篇文档绰绰有余了,我简单的总结了下涉及到的,也是我关心的方面:
1. 从监控的角度出发,官方提供了 API 方便调用,
2. 用户、log audit/forwarding 同样在 web portal 上简单的点点就完成
3. 用户的认证方式也是支持多种,包括默认的 build-in 方式以及 LDAP 等
4. 数据的备份异常的简单,根据文档,几条 cli 就能搞定
5. 使用 virtualbox/VMware 来创建 instance,倒入证书、升级版本、迁移也是异常的方便
6. 如果磁盘用量规划不足,临时的增加 block device 也是异常的快捷

文档的价值有多高了?比如在指导你做 upgrade 的时候,会很明确的提示你:

  1. Shut down your Enterprise virtual machine.
  2. Take a snapshot of your virtual machine.
  3. Boot your virtual machine.
  4. Enable Maintenance Mode.

还有其他需要关注的吗?没了,就是这么简单。如果还有文档上没有涉及的问题怎么办,直接开 ticket,他们工程师反应时间、回答问题的质量以及态度跟 RedHat 是一个级别的。
要是 github IPO 了,我会长期持有他们家的股票的。放张很早之前我司某早期工程师破解的截图,现在我们已经「改邪归正」,早用官方授权的 seats 了。

 

APCN-2 中断 & 海底光缆 101

作为互联网或者说全球性的物理网络中极其基础重要的设施,一直比较低调,很少会有人去主动关注他,他就像空气水一样的理所当然的被人习惯性的遗忘,导致出了问题才想到有这么一个事物存在,空气差了人们会想到开净化器带口罩,但是光缆中断了一般人还真没辙,比如前些日子 APCN-2 的中断,影响的不仅仅是 CN,包括 PH 在内的很多国家都受到了影响。
先说说 APCN-2 的问题。
亚太2号海底电缆(Asia Pacific Cable Network-2,APCN-2)是由 26 个投资机构共同发起筹建,连接亚洲国家和地区,全长约 19000km 共有 10 个登陆站,中国登陆站包括上海崇明和广东汕头。骨干路径由四对光缆组成,通过 Dense Wavelength Division Multiplexing(DWDM) 技术使得最大带宽达到了 2.56 Tbit/s,目前带宽应该是 06 年第二次升级的 280Gbps,每组光缆的传输速度达 640Gbps(10x64x4),采用具有自愈功能的环型网络结构。中国电信、中国联通均参与了此条海缆的建设。最权威的信息可以看这里

3 月 21 号 APCN-2 的 S4A(Chongming, China 到 Pusan, Korea) 发生了中断,3 月 24 号,S6(Tanshui, Taiwan 到 Chikura, Japan) 又发生了中断。 大致的中断位置可以看这里。由此因此了大面积的丢包也不足为奇。4 月 7 号终于恢复了


关于海底光缆是如何铺设的,Quora 上有几个科普性的问答:
* How are major undersea cables laid in the ocean?
* How would you go about laying undersea fibre cable?
* Do private telecommunications companies own the undersea cables that connect the internet across continents?
* What is the cost of laying high voltage underwater, sea or fresh, copper cable, dollar per meter or $/km?

上面的还看不明白?百字不如一视频,直接看 discovery 上的这个视频吧,这个纪录片描述了 Tyco Telecommunications 旗下的光缆铺设船 Tyco Resolute 铺设从 Costa Rica 拉一条光缆衔接到 Pan-American Crossing (PAC) 主光缆的过程。看到那么霸气的 monster,我还是蛮期望有机会上去呆两天的。

几家跟之相关的铺设海底光缆的公司,有兴趣的可以进去浏览浏览,看上去都是财大气粗型的:
* http://www.k-kcs.co.jp/english
* http://www.subcom.com/home.aspx
* http://www.te.com/en/home.html

Continue reading

机器与人

机器跟人是两个不同的物种,目前,我的工作 60% 跟前者打交道,剩下的 40% 会跟「五光十色」的程序员、产品、运营、市场等打交道(总算不要跟销售打交道了)。
总的来说,机器比人好管理好沟通的多,因为机器没有欲望,你让他怎么做他就怎么做。当然如果你对他不熟悉不了解就想强上,一般情况下受伤是你自己,所以如果不想出现一些悲剧性的后果甚至是灾难性的,因此最好需要花时间去熟悉,然后再驾驭。
不管是机器还是人,最终都是服务以及被服务的关系,比如 A 机器提供 API 给 B 机器调用,这个可以看成是一个 client/server 的模型,如果 A 机器出问题了,对于 B 机器这个独立的个体来说,最坏的情况是 crash 了,更普遍的情况可能会是 stderr 或者打 log,你可以通过调查这些蛛丝马迹发现 A 「不爽」的原因。

人就不一样了,第一人有欲望(除非你信佛教),第二众口难调,举三个亲自经历很有代表的例子:
1. 公司每天中午的饭菜,我从 11 年吃到现在,吃了三年吃腻了,有时闻到油的味道就不想入口,当然有不少跟我同等感受的同事;但是观察下来你会发现,还有一部分同事看上去吃的蛮香的,并且跟他们讨论下来,他们也觉得饭菜还不错。这个是一个典型的众口难调的例子,期望不一样,结论也不一样,这不是期望越高失望越大么。至于什么出去玩,你想去 A 地我想去 B 地的问题那就更多了。

2. 上面说的是日常生活方面的,下面说两个技术层面的,虽然跟我们的 production operations 关系不大,但是原理是相似的。

2.1. 11 年我刚去友盟的那会儿,兼职接手了当时新办公室内部网络部署的摊子,没钱没人,只能让着我们的行政小姑娘帮忙打打杂,花了半个多月的时间搞定,信心满满的给第二天要搬到新地盘办公的员工发邮件告知。后来总结起来发现这事面向的是普通观众,大部分人都是不懂 tcp/ip 的,包括众多的分不清 gateway 为何物的程序员,而我当时写的又比较的专业,设想的情况太美好不切实际,比如竟然想到通过静态 IP 而非 DHCP 的方式让每个人去访问网络,所以当时的反馈并不是很好,收到了各种各样有理的无理的回复以及善良的建议,接下来又忙活了接近了 1m,才终于解决了这个问题。后期又总结了下出现这个问题的原因:
* 技术层面也就是网络的实现部署太过理想化,所以面对的大众即使是工程师的环境,也应该使用 DHCP 而非 staic IP
* 其次,对我们的客户的信息的传递上,普通客户就应该使用普通朴素的语言,最好能 step by step 的截图告知怎么操作
* 另外一点就是在出现问题之前没有综合的考虑可能出现问题的各种情况,不然等真出现问题再考虑就有点晚了
* 非主观因素就是,你面对的是一大波的客户,那就更面临着被骂的风险,这个做运营的因该很有体会,尤其是专门维护公司 twitter、weibo 账户的同学,应该是经常能搜到客户的不满以及发泄的,所以,这事最终的结论就是自己先把份内的工作做好,先满足大部分人的要求,在时间精力允许的情况下,再去满足那一小部分人的欲望以及口味

2.2. 第二个是关于我们内部的代码托管平台 github enterprise 维护的事,这事也是我前几个月接手。然后做了两件事,第一个是把我们的 instance 升级到了最新的版本,这个完全没有影响,第二件事是出于安全的考虑,将原来的公网可访问变成了只有通过 proxy 才可以访问内网的方式。这事从技术实现上来说同样不大,换下端口改下 IP 就好了。我索性快刀斩乱麻,加上前期准备花了不到 3h 的时间搞定了所有技术层面的事情。比较麻烦的是在告知我们的客户,也就是所有的友盟员工发生了这件事的大致经过以及结果以及最重要的,对他们的影响。吸取了之前的教训,再加上处理多了这类事情之后自然就轻车熟了。所以在使用了很通俗的语言描述了访问方式变化之后,排除一些垃圾回复(完全 OT 的,自己机器原因无法访问的)得到的反馈还是很正面的。

总之,跟人打交道是门学问,尤其是服务一些吃力不讨好的对象更是如此,要解决这个问题,无外乎这几条路径:
* 尽量少动,专业术语叫少变更,不到万不得已,不要手贱去惹事,实在要做,做之前问下自己,真的要做吗?
* 准备好事后处理的艺术,正如我 2.2. 例举的那个案例一样
* 做完之后正确的区分合理不合理的反馈以及建议,对于不合理的甚至是扯蛋的反馈,有时间有心情就回复周知一下,没时间直接 mute 就好,你很难满足所有人的胃口
* 交给别人做,把自己从火坑里面解放出来,迎接下一个火坑的到来

总的来说,跟机器打交道很简单,跟人打交道相比要复杂的多,有的时候后者或许比前者重要的多。

耗时半个月排查问题的小结

这次是最近遇到的比较 tricky 问题的升级版本,当然他们二者没什么关系了,基本上我这半个月的时间都耗在这上面了,尝试了各种手法,包括 systemtap, dropwatch(感谢 @bitstream 的帮忙),不管如何,最终还是在我们 director 的帮助下一起解决了,虽然最后的 root cause 不是什么很高深的理论,懂点 TCP/IP 的应该都能理解,但是整个排查的过程我认为还是很值得参考的。本次 debug 仅仅涉及到 IP 层以下的内容,跟上层应用没有什么关系,对 IP、MAC 等数字不敏感的建议不要读了,即使要读也务必理清楚了再往下,下面会涉及大量的 VLAN IP 段,如果想知道最终的结果,直接跳到最后就好了。

在升级完我们所有的 10G 网络之后,出现了如下的现象。
1. 所有只配有一个内网的机器没有任何的问题,通过默认的 GW 可以访问其他 VLAN 机器,比如这个,默认都通过 10.118.10.250 出去:
jaseywang@u9:~$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.118.10.0      0.0.0.0         255.255.255.0   U     0      0        0 eth1
0.0.0.0         10.118.10.250    0.0.0.0         UG    0      0        0 eth1

2. 所有配有公网的服务器到一部分内网的 VLAN 不通而到另外一部分内网 VLAN 则是通的:
jaseywang@un10:~$ ip add
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 78:2b:cb:53:d6:55 brd ff:ff:ff:ff:ff:ff
    inet 111.111.111.230/26 brd 111.111.111.255 scope global eth0
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 78:2b:cb:53:d6:56 brd ff:ff:ff:ff:ff:ff
    inet 10.118.10.20/24 brd 10.118.10.255 scope global eth1

root@un10:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
111.111.111.192 0.0.0.0         255.255.255.192 U     0      0        0 eth0
10.118.20.0      0.0.0.0         255.255.255.0   U     0      0        0 eth1
10.118.10.0      0.0.0.0         255.255.255.0   U     0      0        0 eth1
10.111.0.0       0.0.0.0         255.255.255.0   U     0      0        0 eth1
0.0.0.0         111.111.111.193 0.0.0.0         UG    100    0        0 eth0

root@un10:~# ping 10.118.20.1
PING 10.118.20.1 (10.118.20.1) 56(84) bytes of data.
64 bytes from 10.118.20.1: icmp_seq=1 ttl=63 time=43.6 ms
64 bytes from 10.118.20.1: icmp_seq=2 ttl=63 time=30.4 ms
^C
— 10.118.20.1 ping statistics —
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 30.453/37.054/43.655/6.601 ms

root@un10:~# ping 10.111.0.1
PING 10.111.0.1 (10.111.0.1) 56(84) bytes of data.
From 10.118.10.21 icmp_seq=2 Destination Host Unreachable
From 10.118.10.21 icmp_seq=3 Destination Host Unreachable
From 10.118.10.21 icmp_seq=4 Destination Host Unreachable
^C
— 10.111.0.1 ping statistics —
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4008ms
, pipe 3

当时我在现场发现了这个问题,看路由表,写的好像有些问题。抱着试一试的态度,反正也是不通,死马当活马医,找了一台有问题的机器把之前的:
root@un10:~# route add -net 10.111.0.0 netmask 255.255.255.0 eth1
改成了下面的这种方式:
root@un10:~# route add -net 10.111.0.0 netmask 255.255.255.0 gw 10.118.10.250

「神奇」的是,竟然 work 了。现场任务繁重,没有那么时间仔细考虑,恢复系统要紧,我很快把我们剩余的出现问题的机器都按照这种方式修改了 route。至此,线上的机器总算能恢复正常了,虽然当时不清楚为什么。回来之后,当然要做详细分析了。为了复现当时的问题,我又找了几台机器。

Continue reading