如何快速解决技术故障和危机

问题都在

如果给我一根杠杆，我可翘起地球。如果给我时间，我可解决一切问题，或许几分钟，或许几年，或许趋近永远。

不谈成本的策略就是耍流氓。不同公司，不同业务场景，不同规模，应对方式不可能完全相同，适合自己的才是最好的。

有备无患

这里的备，是狭义的备，就是数据备份。持久化数据备份，操作系统的备。对于目前的IaaS层，一般都有完整的机制，对于小规模系统或单机系统，管你是中病毒、被恶意删库，突然硬件故障等，备份是你的保留招，无法做到业务不中断，业务不丢数据，但尽可能减少了损失。

架构简洁

简单而不简陋。在牛逼的架构，新人不好理解、老人不好维护就不是一个好架构。架构是为解决问题而产生的，而不是有了架构才去解决问题。如何做功能完整、运行稳定、性能优异且维护简单？局部由于历史积累或业务原因可能存在复杂度，但整体结构应该是简洁的。

持续改进

最求简洁是一个目标，但总有一个认知局限性。变是永恒，变是就应该为了解决问题并尽可能结构上更简化，如果结构更复杂了，那得跳出当前问题更全局范围反思解决方式是否合适。

问题发生

边界很重要，在复杂的软件最终总是被分解并团队协作完成。数据流划分好节点，故障后锁定范围，通过剔除故障服务和引流快速恢复。目前以kubernetes为基础的云架构有很多解决方案，主要还是如何落地并结合好业务问题。

按需选择

对于小应用或小企业应用，7*24只是梦想，早期软件体系能上个集群就不错了，稳定性不单软件问题，还有硬件问题。硬件层面公有云厂商资源可靠性要比自建服务器好很多，毕竟就算硬件级故障，也能快速迁移到其它机器。单机应用基于docker这样的容器运行一个单体或微服务，如果不是软件业务层面问题，稳定性都能保证，最差就是健康检查失败后的重启自愈。

有点规模的企业，直接上个kubernetes云架构，这个源自互联网生态的体系，终极目标就是永不停服。当然也还要结合业务来设计业务架构，让整体落地并可持续更新。

互联网大鳄们就更复杂了，除了做自己业务，顺便把自己云服务器推一推，硬件软件一条线全链搞定。网易云音乐前期服务中断两个小时，被大家各种吐槽，按官方说法和现象看，应该是数据有问题导致都用不了，否则可能仅影响部分用户，技术上相信网易应该有充足的技术积累，可能运维过程中存在瑕疵导致故障。

尽量200吧。