03｜淘宝HSF：能让淘宝出重大故障的就那批人

好奇一行代码的问题是什么

🤔☕️🤔☕️🤔 【R】写博客，被关注，写得好，工作自动找上门。 【.I.】项目化的代码，就是为了这个项目而生。产品化的代码，成为产品特性的一部分，因这个特性而生。框架化的代码，成为产品特性背后的空气和饮水，不太容易关注都它的存在，自然而然认为它就该存在，实际上它却是特性代码的生命力来源。写代码的时候，经常提醒自己，现在写的代码，如果是项目代码，那怎么能成为产品代码，如果是产品代码，那如何能搭建起框架，来让产品代码更有生命力。只有这么问自己，才会去倒腾实现的代码，看山是山，看代码是代码，回头再看山还是山，回头看代码还是代码。 【.I.】知道一项技术，会用一项技术，落地一项技术，这里的距离，十万八千里来形容，一点都不过分。类似下面的关系： 【知道->会用 vs 0 -> 1】 vs 【会用 -> 落地 vs 1 -> N】 一般认为“0->1”比较困难，这在科学发现里为真，但是在工程领域里只能算半真。毕竟，工程领域要解决的问题，在科学发现级别上已经被解决。所以，技术领域的“0->1”相对而言，只要花点功夫和时间，总能弄明白。而且，技术领域里的“1”往往是原型系统，或者算实验版本。只有真的落地到实际环境，进入生产系统，跨出“1->N”的步伐，才会发现摸着石头过河，不只是要认真摸每块石头，更要勇气和信心去一块又一块石头摸着过去。 【.I.】一个系统最奇怪的状态，就是感觉它怪怪的，但是说不上它怪在哪里，心里就是这么难受的搓磨感。我之前也经常有这样的感觉，后来发现一个词，叫“失控”。当这个系统跑得很起劲，我只能在外面看到它的输入和输出，无法知道它内部的运行细节时，我做的任何修改，依然只能通过整体看效果，这种失控感就会产生。有时候甚至怀疑，修改到底有没有效果，然后只能用朴实又拙劣的打印来局部确认。这样的系统，带来的最大恶果，就是让修改失去勇气，甚至滋生恐惧感。这时候，对于一个系统的微观架构，能够在框架层面提供诊断机制，让系统的运行时内部过程具有可观测性，就会让修改系统的勇气持续存在，任何时刻都通过观测诊断性数据，来消除内心的这种搓磨感。 【Q】对于一个数年积累起来的大系统，如果想搞明白其中的原理，这样的念头是否合适？如果合适的话，老师是否有推荐的方法？ —— by 术子米德@2022.10.07

好奇大佬是哪里的？😄

看了好几篇才冒个泡，虽然毕玄总是把成事归于“运气”，但我觉得还是离不开技术洞察和趋势判断的，大佬就是谦虚

我的关注点是，机会都是给有准备的人。当你研究某个技术或领域，要研究的深研究的透，并在一定的场合分享让大家知道你，这样会带来意外的惊喜

k8s这个平台也是基于强大的插件体系和可扩展能力；

所有的“运气”都是前期的积累，大佬太谦虚！

运气,也是实力的一部分,老师,真的太谦虚了~~

处理过公司最严重的故障 当时处理故障的时候，使用重启大法就将故障解决了。当时需要先将流量全部摘掉才能重启，否则在重启时大量流量涌入无法正常重启 出现这么严重的故障，心理还是比较忐忑，但是想想先快速解决问题，后面再想后续的事 最后还好这个故障Owner不是我

运气其实是你努力后的一种机遇：如果你不去尝试，不去付出，不去承担，不去探索；机缘不一定会光临你。