本文来自听云客户投稿，如需转载请联系听云College团队成员阮小乙，邮箱：ruanqy#tingyun.com
之前携程DOWN机的事件在业界闹得沸沸扬扬，很多人都在总结分析。其实对此我也有一些个人看法：关于IT系统运维/关于异地灾备/关于私有云。本人正好在三种阶段和规模的互联网电商公司都工作过：
在业界比较知名的互联网电商公司从事过一些基础的工作
参与过比较早期的创业团队(其所有的程序甚至都部署依赖在别人的公有云端)
同时也在处于这两者中间状态的电商公司工作过。
这三段经历让我发现一些共性的问题，借此机会分享出来。
技术的挑战及分析
我发现，不论那些公司的老板或CTO自己有没有意识到，目前几乎所有的互联网电商公司的技术架构演化都在走着一条殊途同归的路：从基础工具(开发/测试/部署/监控/运维)，到运维自动化/虚拟化，最终到私有云（实现弹性计算等）！ 只是不同的公司处于这条路上的不同阶段而已。即便是我前面参与那家创业公司，也开始走上这条路，只是他们的阶段不同。
很多公司的问题并不是没有找到一个更牛的框架或技术来“一招制敌”，而是目前业界解决各个领域问题的框架或技术工具太多了。所以问题反而变成是采用的语言/技术和方案太多，整个公司研发体系都缺乏对这些多样性语言的优缺点的统一的/清晰的认识，并制定出解决方案。从而造成很多附加的问题，以及过高的管理及维护成本。
举个例子：我曾经听一个公司研发主管向其技术管理层汇报其私下采用Node.js的原因，就一句话：“Node.js性能高”。而技术管理层也没有做任何的深究，相当于默认了其以后在任何其他场景可以随意采用的可能性。这里我没有任何贬低Node.js的意思，只是针对这样的决策方式。客观的说，Node.js具有“适用于高并发、I/O密集、少量业务逻辑的场景”，但其也有一定的缺陷以及不适用的场景。在决定采用该语言前技术团队一定要对于其缺点以及不适合应用的场景具有充分的认识。并基于此要求团队拿出相应的解决方案，进行严格把关：
异步编程带来的往往是到处callback（回调函数），代码不够优雅/可阅读性、可维护性差 ；这个时候技术管理层需要考虑：如何通过一些第三方的方法来弥补这些缺点；
针对Node.js的DEBUG不方便，错误没有STACKTRACE是否统一采用类似WEBSTORM这样的JS开发IDE；
Node.js不适合CPU密集型应用(将导致CPU时间片长时间不能释放)
从技术管理层面需要考虑：如何规范程序员不去用Node.js来写真正复杂的业务逻辑？或者说写着写着就写出复杂的业务逻辑。是否应该统一规范为：采用Java来实现真正的业务逻辑，通过JSON API暴露给Node.js调用。而Node.js只做请求转发，将其异步调用的优势发挥到最好；
一般来讲，技术人员更关注于技术本身、关注于自己的兴趣、关注于自己使用某个技术后的个人成长， 这本身无可厚非。但问题在于很多公司的技术管理层缺乏对采用某种技术的推广实施成本，以及实施风险的考量！同时还疏于对于技术带来的结果的关注和追问。再加上很多技术人员普遍不具备结果导向的心态(以'技术本身牛不牛'为导向的技术人员倒是大有人在)。这就会带来很多业务以外的额外的‘技术问题’，系统不稳定/采用技术/框架/依赖性太多，造成问题的排查和定位的困难/修改维护的困难等等。很多时候CEO不理解：“为什么这么一个小修改需要这么多的时间？”答案是：因为你的系统的技术架构已经在你'不懂'或不在意的情况下，通过很多技术人员的‘努力’，'悄悄的'变得远超出你想象的复杂。那种‘重量级’、那种‘高技术含量’已经成为你的创业团队“无法承受之重”了！好吧，这个时候你也不能发火，你还必须得忍着。因为技术人员他们也很努力的在辛苦加班阿。OMG，我可怜的CEO啊。
通常，技术人员都更倾向于去做那些高精尖，听起来高大上的东西。从而忽略那些脏活/累活。例如：对于虚拟化（KVM/LXC/Docker等）的全方位使用、自动化弹性扩容/缩容、一键灾备切换，这样“高端”的东西要想取得成效，必须配合有很多基础的工作，有很多脏活累活要先干好。那么，什么算是脏活累活？
改变程序员不恰当的编码习惯，比如：喜欢将用户名和密码、URL、各种其他配置等硬编码在程序中。你必须要求他们将配置参数放在固定的位置，甚至于提供统一的配置管理系统和服务。才能实现更好的配置管理，实现所谓的‘自动化部署’;
对应用系统的改造: 为实现‘跨机房双活’这样的目标，应用本身应该是'无状态化的'。为实现在异地机房程序的快速'恢复'，必须降低各种依赖：IP依赖、服务依赖。为此，有必要提供内部统一的DNS系统，将IP依赖改造为域名依赖。提供服务治理系统，将跨语言、跨协议的服务进行统一的管理；
对于研发/运维人员进行虚拟化基础技术培训，包括虚拟化对于资源的处理，对于基础的安全性/隔离性等方面的培训;
对于消息服务/缓存服务/数据库服务这些‘有状态’的服务，采用专有的跨机房双活的集群方案、同步策略以适应异地灾备机房的一键切换，以此来保证该种情况下的数据一致性/消息不丢失/缓存的有效性;
对于基础的统一监控的推广，以及对虚拟机基础监控，虚拟机中的应用监控/服务的监控等;(必须有一套合理的机制能预见或者说即时的‘计算’出某服务的‘负载’情况，才能实现弹性计算所谓的“自动扩容/自动缩容”)
对于基础的‘编译打包’‘自动部署’的推广使用，对于类似统一日志传输这样的基础设施的建设和推广;
建立构建和测试的标准化流程；
以上这些工作本身的技术含量有高有低，听起来也不像什么“高端大气”的工作。但是很多大型互联网公司看似只有一个简单的网站/一个APP，在后端动辄有数十上百甚至上千个独立运行的程序，很多程序又在不同的主机上部署了多个实例，成百上千的服务器。需要推动相关的研发负责人在不影响业务快速迭代的同时去实施这些优化、实施这些基础工具、实施这些流程/规范。基于此，我将以上这些工作称之为“脏活/累活”。当这些“脏活/累活”以及基础的自动化工具和流程规范实施到位后。所谓的‘弹性计算/异地灾备/高可用/私有云’其实是自然而然水到渠成的事情 ;
应对办法：
技术架构的优化
确定公司统一的架构原则，类似全面服务化、URL规范、配置原则等等；
SLA体系的建立
通过实施内部专用的'业务监控'以及配合一些外部专业的监控产品，让每个系统或每个服务的整体服务水平透明化。并且使得各系统之间/各服务之间可用性的横向对比变得可能。透明化将为管理层的监管/考核提供更好的手段和依据。最终有利于全公司所有系统SLA(服务水平)的提升; 同时，通过更好的实时监控推广监控来提升事故出现以前的预判能力，及事故出现后的更好的曝光和及时的处理；
笔者所在的公司采用听云的专业监控产品：network、移动监控等，通过在监控产品后台配置合理的监控报警策略也帮助我们及时的发现问题。
听云发送给运维/研发的报警邮件
工具系统的建设/推广
通过自动部署、统一配置管理等系统的实施：让运维从繁重的上线工作中解脱出来，有时间从事更多的保障硬件/交换机/灾备/机房高可用等事项；自动部署系统提升上线效率的同时提升线上操作安全性，进一步降低上线造成的事故几率。通过内部DNS系统以及服务治理的上线实施以降低运维线上IP依赖、提升服务的规范性及可管理性，以及快速“恢复”的能力；
规范体系的建设
流程/规范的建设应该是伴随着工具系统的建设，相辅相成。借助工具系统的推广来推行流程规范的落实，通过流程规范的落实反过来加强和优化工具系统的建设;让工具系统的方便性就像互联网产品一样吸引住研发。通过这种使用的粘性反过来加强流程规范的推行！
工具系统和流程规范之间的关系，以及最终走向私有云的路线
总结
有人说：针对一家业务高速发展中的互联网公司的基础架构的改造无异于是“为一辆高速行驶中的赛车更换轮胎，车辆本身还不能停”。而我个人更欣赏“磨刀不误砍柴工”，当你的业务跑了一段时间发现系统负载过高，你自然要去改造你的某些基础架构以带来更好的响应能力。自然要去实施一些基础的自动化工具，以便更好的监控和改进系统以及更高效和可靠的部署。并且推出一些跟当前团队技术能力和‘自动化工具’相匹配的“流程/规范”。这种做法是一种渐进式的演变和优化，不会对业务的运行本身带来太大的风险。也不需要暂停业务；
相反，我们如果因为遇到某些技术问题，下了一个决心采用了一些更“高端”的做法尝试‘永远’解决该问题。最后会发现新采用的技术引入的新问题，付出的成本比原问题本身更严重。
以上想法，分享给各位老板/技术总监/技术人员。共勉之！
分享到微信
分享到微博
