术子米德2020-12-20🤔☕️🤔☕️🤔 有个小困惑，生产系统，有人加个索引，这个操作本生没有被监控和日志下来么？ 按理说，生产系统的任何改动，都是要被监控和日志，这本该是生产系统监控最基础的工作，否则就像案例中的样子，问了半天都不知道系统已经被修改了，这不是有点搞笑么？作者回复: 你好，术子米德 你提的这个问题特别对，这其实也是写这篇文章的初衷。对于发布要进行监控，是这样的。这个也有监控，在发布平台也有，但是对应的DBA的忽略掉了它。这就是认知太重要的原因，大家还是要去寻找bug的思路，而不是寻找变化的思路。而大脑很神奇，就彻底忽略了它。 而当时又是下班后的时间，大家也没有去发布平台看，就相信了当事人。 很多问题事后回顾都是这样，哭笑不得，生产的问题大概如此，这也是这么多年看生产问题得出的结论。所以才总结出不是寻找bug，而不是寻找变化的恢复思路，这个认知特别重要，其实今天很多企业，也没有得出这个认知，你想想是不是？
共 3 条评论17
yshan2020-12-18笔记整理： 1、监控的目标是及时发现系统的问题，并尽可能快地做出相应的动作，让系统一直处于健康的状态。监控，可以拆分为“监”和“控”分别理解，其含义恰好对应着两种主要手段，也就是“监视”和“控制”。 2、监控是为了让系统一直处于健康状态，具体的手段包括“监视”和“控制”两种。 3、生产环境出现问题，原因通常只有两个字：变化 4、变化：①外部用户请求量增大；②产品发布，一般包括代码发布、配置发布、SQL 脚本发布等； ③依赖资源变化，一般是计算、存储、网络基础设施情况变差，比如磁盘存在坏道等。 5、流控和版本回退。流控，就是做好程序的并发流量控制；版本回退，就是在生产环境的发布出现问题时，及时回退到上一个版本。 6、只要我们控制住了服务的近期变化，也就等于控制住了故障 7、生产环境是不允许查找 bug 的。在生产环境，研发人员应该寻找并消灭“变化”。从寻找 bug 到寻找变化，是一个非常大的认知转变。 8、生产环境永远不允许调试问题，出现问题立刻回退，查问题要去测试环境。 9、大版本立项，小版本上线 —— 梳理好各模块的依赖关系，将各个系统、各个服务独立发布。当然，这也需要依赖服务版本化和 CI 能力的支持。 10、监控的目的是让系统一直处于健康状态，具体手段则可分为“监视”和“控制”两种；要做好控制，一个重要的方法是做好流控和版本回退。因为在大部分情况下，消除变化就等于消除异常。展开作者回复: 你好，yshan 总结的真全面，真棒
共 2 条评论14
Weehua2020-12-21学习了这篇文章，真的感同身受。我们的研发过程中，线上遇到问题几乎大部分都是变更引起的故障，所以第一时间回滚是强行要求，先止血，恢复业务，然后复盘分析，修复解决问题。监控，监是比较容易的，控反而是困难的，怎么让系统在遇到问题的时候快速恢复才是核心。当然，能及时发现问题也是很重要的。作者回复: 你好，Weehua 简单的办法但最管用，因为符合本质。
3
Tony.xu2021-03-05乔总，您好！本节的方式&方法都很OK,很多大的公司也是在这么做的。听了这个索引的案例，我有一些补充的思考，分享一下。 1）全局性回退问题：不光是代码还有脚本这个不管是之前的普通运维方式还是DEVOPS都是应该严格准守的。 理论上来说应对这种方式的操作应该在每次上线前，确定好应急回退版本和对应回退脚本，做到一键回退。因为在回退问题指望团队 人员的回忆肯定是不靠谱的，建立应急回退制度，不但能提升团队专业度，也可以提升问题的解决效能。 其次，一定要杜绝不按照预定版本回退，也就是做到统一版本回退。如果在一个版本上线后，有一些零星更改，应该在之前的回退版本中加入补充，最好做到能够根据修改管控到既能逐级回退，也能全局回退到上一个大版本。 比如1.0--》1.01--》1.02--》2.0 （即便1.01中只是加了个索引）， 回退方式2.0--》1.02--》1.01--》1.0（这个不停留于理论；管理的好是完全可行的） 2）数据库脚本问题：理论上讲，数据库脚本加入索引等类似动作，是需要DBA审核的，因为研发同学对DB的认知和专业DBA是完全不在一个层次上（在一些场景下并不是加入索引就一定快的，很可能有后遗症），如果贵司这个案例之前有DBA审核机制可能就能提前杜绝这个问题。如果没有DBA，可以让团队对数据库专业领域知识很强人员替代。这个问题不是一个个案，很多公司都遇到过，其实是研发的数据库认识能力不强导致的（针对这点可以进行后续培训的）。 综上所述，遇到产生问题，第一时间能做到全局回退，而且很清晰的明白回退的版本节点，在事后的问题分析中，抓到本质原因，如果是非常特殊的情况建立记录以供所有团队参考杜绝再次犯错，如果非个案，建立后续制度进行管控。 浅见啊，希望乔总砸砖，哈哈展开作者回复: 你好，Tony.xu 思考的都特别好，这些实际就是我带领的团队都一直坚持的内容，加油。
共 2 条评论1
Y024
2020-12-20其实就“平平无奇”的 log 记录，很多人/产品/项目都做不好，出了问题都只能上重型武器——ide debug。作者回复: 你好，Y024 是的，其实记好log，本身时监控体系的一部分，如果数据都不对，不准确，后面在寻找问题时会出问题。这也是为什么我们寻找变化，而不是寻找bug的原因，很多信息都没有记录，所以难以定位。
1
worfzyq2020-12-18错误一问题存疑，具体可能得看业务场景，如果涉及到c端业务肯定不能草率回滚，另外很对功能上了在下会有pr风险，当然确定这些没问题了确实可以这么做。作者回复: 你好，worfzyq 谢谢提出问题，我们来讨论一下。 第一，现在有问题，不回退，是业务有问题，甚至是不可用，两者权衡，取舍如何做决定，回退是最优解，因为回退的版本是业务可以正常运行的版本。 第二，发布是在业务低峰期，比如一般公司是在晚上，这时候回退了，查明问题再进行发布心理压力多小 第三，回退带来的问题就是上线失败了，但是业务不受影响；而不回退是业务受影响。如果我们不能保证每次发布一定成功，就必须有应对方案，回退就是一个保底的应对方案。回退+发布在业务低峰期，我的职业生涯中认为就是最优解决方案；回退在项目层级是不好，在业务层级对于业务影响几乎没有，是在发布失败时的最优解。 我们一起讨论，也可以结合一个具体的案来看看，是否还有更优的解，再次感谢提出问题。
1
Jy2020-12-18确实是很好的做法，但我们公司还没能做到这一步，只能逐步改进。 比如业务逻辑出错导致的前端或者后台报错，能监控到但没后续，有一键回滚的能力但回滚了整个这方面的业务功能也就没了，业务不能接受，还是需要花时间来调试补上线。 想问下乔老师有无遇到这种情况呢？作者回复: 你好，Jy 回退应该是回到上一个稳定的业务版本，这个是在发布前就准备好的。 对于大项目，一个大版本发布的组织，这点比较难，但真的是把自己置于险地。只能在线上解决掉问题，团队的心理压力太大了。 我职业生涯碰到过，所以我再也不想再碰到这种情况，从理论上、概率上就彻底消除掉这种情况，那这个研发过程多轻松。
1
花花大脸猫2022-05-26回退这个有点不一样的看法:比如有些时候我们的系统是配合外部公司的系统一起上线完成一个闭环业务的，并且外部也明确了必须要能提供业务功能，这时候就不是简单回退能处理的了的？尤其是面对业务上很强势的业务公司，这种情况下，请问下老师有什么解法？作者回复: 第一，一定要有B计划 第二，如果一定是破釜沉舟，必须成功，那就要控制好研发质量，确保不会有问题。监控体系，测试覆盖率，同行评审，代码走查都要做到万无一失。
奔跑H赛道2021-04-09您好，我在听老师讲例子的时候就猜到可能是数据库出的问题。像我们发布软件，都要走change management 流程的，但是我觉得数据库好像change management 届黑洞般的存在，就算有日志，排查问题和回滚的时候特别容易忽略。经常使这种发布无法做到atomic作者回复: 你好， 暗夜微光 持续完善，CI，CD，CO，肯定可以达到的。
知行合一2021-03-11乔总，很久没留言课程了，因为有点时间没有看课程了。这一讲让我收获一点很关键，找bug是为了解决问题，往往思路却被找bug和解决bug局限了。还是需要全局观，意识到恢复功能比找到bug价值更高，思维才不会被局限。换维思考，大繁至简，专业度就提现在简化过程上。 之前跟您分享，我发现了自己的选择方向，准备做出转变，提升上限。不过发生了很多阻碍，自己停滞不前。决定好做，迈出第一步也不难，难在坚持啊。很不顺利，就会很沮丧，想方设法的让自己维持好的心态，负重前行。 最近半年给我留下印象最深的，就是乔总的课程，说过的话。我也经常在工作中引用。感谢作者回复: 你好， 知行合一 太棒了，学以致用，是最好的学习效果