摘要：等研发介入时，现场已经不复存在。因此，我要求戒律一凡是中间件，不管是自主研发的，还是以开源软件为内核构建出来的，都必须自带监控报警，否则不允许上线。
郑昀（公众号：老兵笔记） 20180411
如果你在繁忙的业务迭代中开始系统重构，恭喜你，说明你的业务已经完成了从0到1，正在从1走向10，或者从10走向100。
至于重构后的技术栈是 Spring MVC+Dubbo，还是 Spring Boot+Spring Cloud？
是 Vue+ElementUI，是 React，还是 Ant.design，抑或就是上古时代的 JQuery+Bootstrap？
是 k8s，还是 mesos+marathon？是 Thrift，还是 Hessian，抑或 Protobuf？我并不在意。
我并不 care 这些东西，每个技术团队都可以有自己的技术选型思路。
我在意的是两个“是否有利于”：
一，是否有利于发布部署。
二，是否有利于排除故障（是否有利于快速定位线上问题和解决问题）。
为什么要强调它俩？
因为我们在过去六七年间，经历了太多的生死折磨。如履薄冰如临深渊。
我们曾是做本地生活服务电商的，餐饮/电影/酒店/景点门票/美容美发……
节假日往往也是本地生活服务的峰值日，饭点儿就相当于秒杀。
太多次在假期被召回。
太多次打电话给各个 TeamLeader，有时电脑不在身边，有时深山老林无法上网，有时无人接听，有时 VPN 连不进去～
多少次翘首期盼 DBA、SA、QA、DevManager 们给我回报到底出啥事儿了。
请先阅读一下我写的《经历不可抗力是一种什么体验》，了解一下什么是 too young too naive。
以至于我有两个怨念：
怨念一，Centreon 烂到渣，Zabbix 也不咋的，基础运维的那些神兵利器，都不考虑做业务的人，尤其是业务集群规模庞大的人，到底是怎么排查问题排除故障的。
SA 是怎么工作的？
一旦出现连接数暴涨，Web/App 服务长时间无响应，应用内存飙升，SA 拍马赶到，一定是先重启相关应用（不管是容器还是虚拟机），如果还不管用，就立即将相关应用悉数回滚到上一个稳定版本上，争取以最短时间恢复。
等研发介入时，现场已经不复存在。
六七年前，事发后，我们登入 Centreon 和 ELK，按机器组、按机器、按指标，用肉眼，用大脑，结合各个业务集群里的日志，结合 Nagios 报警短信，理出来一个因果证据链。
你可能需要打开几百个监控页面，你还需要精通业务集群的分组、调用关系和IP（那时候还没有 Docker 容器，都是虚拟机）。
这也就是为什么我定下我司研发哲学第一条：Don"t make me think……
怨念二，开源软件的开发者是好人也往往是性情中人，不太考虑排除故障成本低、可视化、高可用、可伸缩、监控报警等商业系统必备的运维属性，拿来主义必死无葬身之地。
举个例子吧，ActiveMQ 和 RabbitMQ 有生产者流量控制，如果你没有听说过，没有遇到过，恭喜你，但也表明你的业务量还是太小。
你可能会说，遇到了生产者流量控制，说明下游消费者消费得太慢，加快速度不就完了？
在电商服务中，异步消息队列的消费者往往是与第三方系统网络通讯，第三方系统可就不在你控制范围之内了，一个第三方系统挂了，或者突然拥塞，就会憋住你的消费者集群的所有线程，造成消息积压。因此就将上游生产者挂起？开玩笑呢吧？！咋想的这都是？让灾难从下游蔓延到上游？！
那么我们应该怎么思考系统重构呢？
随着业务规模越来越大，随着应用越来越多，随着 Docker 容器集群的引入，随着前后端分离导致内部接口越来越多，随着 API 网关的引入，我们越来越难以在5分钟之内断定系统出了什么事儿。
因此，我要求：
戒律一：凡是中间件，不管是自主研发的，还是以开源软件为内核构建出来的，都必须自带监控报警，否则不允许上线。
戒律二：本着 Don"t make me think 的哲学思路，所有对排除故障有帮助的信息，都必须一站式展示在交互界面上，也就是在中间件的控制台上，或运维自动化平台上，或研发协作平台上。
下面举一些具体的例子，帮助大家理解。
我司的技术支撑体系如下图所示（或点击查看原图）：
其中：
1，定时任务管理与调度平台有运行情况展示，自带监控报警：
2，异步消息可靠推送系统有可视化的内部详情展示，自带监控报警：
3，分布式并行计算调度与管理平台一站式展示工作流下每一个任务在所有节点上的运行日志，并自带监控报警：
4，大数据协作平台自带监控报警：
5，我们甚至要把所有 PC 客户端，所有智能设备都监管起来：
6，研发协作平台一站式展示应用部署的方方面面：
可以说我们打造的每一个中间件、协作平台都体现了戒律一和戒律二。
不需要东奔西走，四处收集蛛丝马迹。
不需要一次性点开几百个指标页面，脑补推演。
不需要精通集群部署结构。
不需要熟知应用日志的路径。
对，这就是为我这样的“旁观者”、“小白”准备的。
有了这些系统，即使大家都出去玩了，我一个人也能看出问题所在，同时也能有效应对铁打营盘流水兵的情况。
当你完成了从0到1的跨越，正在从1走向10，走向100，请记住下面的忠言：
两个“是否有利于”：
一，是否有利于发布部署。
二，是否有利于排除故障（是否有利于快速定位问题和解决问题）。
两个戒律：
戒律一：凡是中间件，不管是自主开发的，还是以开源软件为内核构建出来的，都必须自带监控报警，否则不允许上线。
戒律二：本着 Don"t make me think 的哲学思路，所有对排除故障有帮助的信息，都必须一站式展示在交互界面上，也就是中间件的控制台上，或运维自动化平台上，或研发协作平台上。
-EOF-
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/8034.html
摘要：关于与的区别，网上已经有不少文章了，在此不多谈。主要想谈的是在制作网页时，什么时候设定字体大小用，什么时候用先谈结论，再讲为什么。一般情况下，还是以用为主，只有当需要在不同设备上显示不同大小的字体时，再用。 关于rem与px的区别，网上已经有不少文章了，在此不多谈。主要想谈的是：在制作网页时，什么时候设定字体大小用px，什么时候用rem？ 先谈结论，再讲为什么。一般情况下，还是以用px...
摘要：本章我们来聊聊重构造成的灾难性毁灭。看到这里即可明白重构造成的灾难性毁灭是在年的时期发生的，那个阶段在技术不够扎实但还有一股子改变世界的劲头发生的问题。 showImg(https://segmentfault.com/img/bVbjDK2?w=1734&h=682); 前言 这章我在7月20号的时候就准备好了标题，在那之前有写过一篇重构的文章，这段时间一直在等重构造成的弊端。 庆幸...
摘要：本章我们来聊聊重构造成的灾难性毁灭。看到这里即可明白重构造成的灾难性毁灭是在年的时期发生的，那个阶段在技术不够扎实但还有一股子改变世界的劲头发生的问题。 showImg(https://segmentfault.com/img/bVbjDK2?w=1734&h=682); 前言 这章我在7月20号的时候就准备好了标题，在那之前有写过一篇重构的文章，这段时间一直在等重构造成的弊端。 庆幸...
摘要：前端切图神器前端掘金安装前端的基础工作就是把设计师的设计稿还原成前端页面，所以切图是作为一个前端的基本技能。 腾讯 Web 工程师的前端书单 - 阅读 - 掘金作者：link 2014年一月以来，自己接触web前端开发已经两年多了，记录一下自己前端学习路上看过的，以及道听途说的一些书，基本上按照由浅入深来介绍。 JavaScript 入门 《JavaScript权威指南（第六版）》 ★...
摘要：服务端任需要进行校验来达到数据的可靠性前端的路由可能在服务端并不存在等等这一系列重用性的问题。串行并行，大幅缩短请求时间。关于作者本人主页本文部分图片段落参考文章淘宝前后端分离实践微信公众号会不定期推送前端技术文章，欢迎关注 一、背景 书接上文，浅谈前后端分离与实践(一) 我们用mock服务器搭建起来了自己的前端数据模拟服务，前后端开发过程中只需定义好接口规范，便可以相互进行各自的开发...
阅读 1410·2023-04-25 18:19
阅读 1905·2021-10-26 09:48
阅读 880·2021-10-09 09:44
阅读 1504·2021-09-09 11:35
阅读 2854·2019-08-30 15:54
阅读 1800·2019-08-30 11:26
阅读 2176·2019-08-29 17:06
阅读 776·2019-08-29 16:38
