为今年5月冠上多事之夏的名头已是无可厚非的一件事，自支付宝光纤被挖断后,携程又暴出全站瘫痪的风波,从5/28 11:00开始，直到晚上11：29分才全面恢复.互联网也是谣言四起,纷纷猜测百度腾讯谁会是下一个灾难的受害者。暂切抛开这些玩笑言论,就携程本次事情引发的思考太多,前车之鉴后事之师,如果携程的事情发生到我们身上,我们该怎么办，抱着这些问题我们来思考

1       全站瘫痪的原因分析

自携程全站异常后,整个IT圈像炸了一样的在疯传着各样YY流言. 前离职高管报复行为;公司高管睡了运维小哥老婆,运维小哥一怒之下物理格式化硬盘;携程收购艺龙后引发商业对手黑客攻击入侵代码;总之众说纷纭.但简单分析即可看到所有的分析均是定位破坏性非常大的行为,因为自携程出事后3h后依旧无法对外提供正常服务,这点对外界的影响非常大,IT互联网行为是以分钟计算金钱,以流量衡量价值的行业,3h对于普通行业可能再正常不过,但对互联网行业而言简直是一场灾难,况且携程旅游行业的出名度,引发巨大舆论也是再正常不过,大家出于破坏性大的角度考虑也是再正常不过的角度.但最终官方给出的解释却让人大跌眼镜.运维人员误发布导致.好吧~黑锅总是需要有人来背的.从如下几个方面来分析吧~

1.1     安全问题

1.1.1           人员安全

     这里的人员安全是指什么级别的人在操作,什么样级别的运维能同时拥有对全业务的权限,携程发展至今,在外界看来只是一个简单的入口页面,其实内嵌的页面和功能很有可能是成百上千的,这样庞大的业务体系如果直接交给一个新手来发布或者初级工程师来操作,那其责任更多的需要规究于领导责任,任重道远,当然,从任何的角度来看,这样的可能性很小,但如果是资深工程师的误操作,那会是什么原因导致这样严重的问题的.这样的问题在dev,test,准生产环境为什么没有发现呢,即使如上几个环境均没有发现,那最后一道保障–灰度环境为什么也没有发现呢?如此发问下来,最少有一点是可以确认的,携程没有灰度环境或者本次发布一定没有走灰度发布,难道本次发布只是一次小发布,没有固化流程?

   案例:

   X公司,业务人员变更,主业务维护人在新人没有完全上手的情况下,疏于协助,致使业务发布项遗漏,导致业务维护延期

1.1.2  固化流程

我们权且认为携程本次的发布是一次小规模发布所以没有走灰度,既然操作变更比较小,那是否有固化的操作列表供运维人员发布使用呢,rm –rf /*虽说低级,但不代表类似的错误没有,身边的例子不胜枚举.固化的流程和操作列表是一次发布的保护神,所以我个人认为,即使灰度环境已经验证过了,但依然出现如上的问题,那只有一个解释,没有固化的发布列表,运维人员纯手工敲打键盘所致.如此看来的话,真的是运维小哥的问题了.

案例:

X公司某业务发布频繁,且时常有凌晨发布状况发生,致使业务运维和其它各部门疲于应对发布类工作且发布压力较大,终有一日,业务运维发布过程中发布checklist遗漏,且为极为重要的操作步骤,导致业务数据回档发布延期且投诉居多,对公司业务声誉收入造成不可挽回损失.后采用自动化类工具固化后,此类从误操作从根本上杜绝

1.1.3  灰度问题

如果说运维是生产环境最后一道保障,那灰度环境就是生产线最后一道屏障. 纯手工误操作和无灰度发布发布问题,不管从哪方面讲对运维都不是一个好的消息.如果说纯手工误操作那最多说明携程招人甚,但如果是灰度问题,那携程的整个业务体系一定是不专业的,浮躁的. 在IT快速发展的国内,整个互联网都以结果为导向,快速生产利益,快速上市圈钱,虽说互联网的体系在不断完善,但大体系中一定有轻有重,利益当道,利益部门的地位和权重一定优于其它部门.

案例:

X公司某业务发展迅速,业务急速扩张,各部门精力及资源严重偏向收益类功能开发和新用户推广类工作,疏于业务夯实业务基础类功能开发及现有功能优化和现有业务思考,全业务在规模非常大的情况下依然采用全服发布方式,多次出现bug但无GM类工具挽救,每次均采用回滚或延期发布方式解决问题.后采用灰度发布后影响面和损失缩小不足原来1%

1.1.4  权限安全

从官方后来的解释来看,没有因为软硬件系统后门或安全类原因导致.但内部人员的安全究竟如何我们很难一语评价. 早在刚到现任公司的时候,做的第一件事就是D/O分离,多次的线上文件丢失,数据异常,均因为开发拥有对线上权限过大导致所有的问题以说不清,找不到结束. 此后,项目权限最小化及测试服环境权限最小化,业务虚拟化推广,此后,妖魔鬼怪类的问题也离我们远去,再无踪影,携程数千人规模是否有类同问题还需要携程内部自查了.

案例:

X公司某业务发布及程序运行用户均为root,业务运维同学某次操作过程中因权限过大人误删除业务数据,所幸没有造成灾难性后果,这么看下来权限过大的问题是埋在地下的地雷,终究会有爆炸的那天,root权限回收,D/O分离,权限最小化—业务的保护伞

1.2     业务融入

据析携程业务部门和运维部门完全分开,代码的管理也只是部分代码交于运维,开发部能自己维护的代码一定是自己维护好,导致这种现象最大的问题在于利益切分,业务部门对服务部门依赖越大业务的利润就要分割的越多,想必公司层面最原始的想法是好的,希望从制度上彻底杜绝资源浪费的情况,各部门自力更生,但导致的直接问题除了各部门资源重复外还有这次的问题应该是所有人难以相像的. 业务最好一道保障伞在对业务不了解的情况下,在问题出现后无法快速调动响应.

案例:

某业务被赋给公司极高期望,各部门及领导均极为关注,压力随之分散之业务及各部门,一时之间造成利益部门极为强势的局面,服务部门均抱极为尴尬应对场面,终因一次不必要事故造成部门间冲突升级并造成极大影响力,各部门高级总监聚集召开紧急会议,甚至部分高层连夜飞回会议中心,终双方抛开前嫌放下姿态共同支持业务

1.3     回滚时间长

1.3.1  备份问题

代码拉取,更新,备份,发布,校验,是一个业务完整的发布流程.看似简单但技巧良多,其中的业务备份是运维和业务的保护伞,如若携程本次问题真是rm –rf /类似灾难性的操作,本机的备份是一定没有了,但远程机器的备份难倒也丢失了吗?~这实在有些让人费解. 镜像或者快照功能也是难得也是做本地的吗?对于携程究竟何种技术细心导致本次细节问题至今仍无消息~倒是UC-王总和阿里–智锦的分析实在合理到位且颇具前瞻性。

1.3.2  SOA业务架构形态

阿里资深运维工程师 智锦 早在携程出官网结论前已神预测到SOA的体系架构是导致携程灾难复建慢的原因.从业务最初形态到至今,早已不是单接口单应用AllInOne的架构,SOA带来业务隔离性的同时也带来了业务的灵活性复杂性, 如UC王总所说,随着业务的越来越大,人员迭代,业务的运维对业务只能增加不敢减少的也是本次恢复慢的主要原因,本次业务代码全丢失后,本次的问题相当于从零开始,而且是在无数旧人迭代和官网瘫痪的巨大压力下完全重构业务. SOA体系带来方便的同时也带来业务的复杂程度提高,任何武器都是双刃剑,使的招数则完全看掌握者,既然已经复杂了,但全量备份,异地或者跨主机备份呢？无论从哪种角度解释都有很多招数可以迅速恢复~到此侧面不同程度反应出携程的虚拟化和备份一定有不足的地方,如此两点够携程运维同学吃好大一锅了~

2       公关问题

相对携程来说,阿里的公关不得不说是专业的,在阿里光纤被挖断分钟级别已经对外公布问题,但携程则完全不一样,时至今日也只有对外一个简单的说法,宕机后数小时后期间公司公关部门完全无所作为,甚至连阿里挑衅的微博引导流量也完全哑炮状态,倒有一块看热闹的怀疑,不禁让人怀疑这公关部门是亲生的吗?实在让人不以为然.

3       学习处

3.1     静态有损服务

好了,现在可以来谈谈携程本次问题优秀的地方,在业务完全宕机后,作为一家大公司,携程的静态有损服务总算给自己留下最后一点尊严.

3.2     请求导流到艺龙

    请求导流,携程对艺龙的收购难道是对未来的预知吗?开句玩笑话了,携程在网站全瘫痪后,迅速把流量导向自己刚收购的艺龙,虽然艺龙不能承受随之而来的并发,但思路最少是值得参考的.