救火队人人知
不好出问题背锅，好了也没人说知道
不知道每天都在干什么
作为一个惹出过和处理过一些严重故障的人，我仍然觉得要做好稳定性，最难的并不是技术，或者更准确的说，技术上在怎么做好稳定性，从代码到设计到变更，都有全面的指导思想和原则，包括大家如果去看很多的故障复盘，在改进措施上基本会看到各种类似的话，但这些思想和原则要落地好，是很复杂的话题，有能力要求，还有更重要的是投入要求，而且并没有银弹级产品说做某件事，或安装一个什么软件，就可以保障稳定性了。
先简单说说技术上，然后再来说为什么难的不是技术。
代码层面关于稳定性的指导思想
我之前说过是不是优秀的程序员，代码是最好的证明，优秀的程序员的最大差别其实就是在代码的鲁棒性上，而这个一方面需要极强的能力，看看netty的代码里对各种边界情况的处理就知道要求多高，另一方面则是需要有投入的保障，否则都在赶进度，自然是会把鲁棒性相关的代码放一边，毕竟很多时候这些代码还挺难体现价值的。
代码要写的鲁棒，很关键的几点：
对输入的边界的控制，确保输入是符合自己的预期的，而不只是文档上写的一些对输入边界的约束，例如最典型的故障是批量操作型的接口，由于批量操作的量超过了预期，直接内存溢出等；
对使用到的API需要有深刻的理解（包括实现原理、代码细节），这个其实对程序员的能力要求是非常高的，这里用到的API包括了语言本身提供的，这也是为什么很多时候大家觉得面试的时候问的非常的细，好像这些技能对实际写写业务代码也没什么影响，但其实只有这样，才能知道各种情况下的状况，从而在真正出故障的情况下能快速处理；
Fail fast，不管什么情况，以保障代码能正常运转是最重要的（最简单的标准是别把资源耗尽或crash），在碰到意外情况下，尽快往外抛出错误是最好的，当然，这个主要是对在线型业务而言。
设计层面关于稳定性的指导思想
在设计层面，关于稳定性的指导思想，很关键的几点：
强弱依赖识别，对弱依赖的地方，确保有各种降级策略，当年阿里某关键系统，就是在做好这点后，稳定性提升了N个档次；
自身能力保护，一定要对自己系统的能力有清晰的认识，例如通常来说在线业务系统的指标通常是每秒处理的请求数，在超出能处理的请求数的情况下，需要尽快fail fast，在线业务做堆积是不好的，容易出问题，像Nginx之类的不一样，但也会对堆积程度有个边界控制；
容灾能力，这个从集群化、到同城多活、再到异地多活，其实都有各种成熟的案例和相应的方案。
对于架构师而言，在设计层面，对稳定性的投入的平衡是很重要的，这个和代码层面还不太一样，代码层面有追求的程序员很多时候自己就会花时间去做到，但设计层面很多对稳定性的投入可能是非常大的，所以会是更大的决策。变更层面关于稳定性的指导思想