互联网
大型
互联网应用堪称熵增理论的绝佳例证。它实在是太复杂了，对运维的依赖程度极高。你眼中看似非常稳定的系统，可能每周一都得运行一个脚本来清理数据，每周二则要运行脚本检查各项依赖，周三又得运行别的脚本检查其他事项，每个月还得定期更新繁杂的依赖项。要是降本了，不管是有意还是无意，比如员工离职时忘了交接某个运维任务，或者交接得含糊不清，那么某个脚本就可能没运行，某个存储位置就可能出故障，某个地方的依赖过期了，导致无法连接其他依赖项，进而系统崩溃。系统崩溃后重启未必有用，要是缓存没预热，系统没有做好快速失败处理，突然涌来的海量请求直接冲击数据库，那数据库就会崩溃，然后再尝试重启，接着又崩溃，这时才想对数据库进行纵向升级，大半天就过去了。表面上坚不可摧的系统，背后说不定是个草台班子。别问我怎么知道这么多，我作为Azure
MySQL的产品经理，负责维护相关功能，看过太多客户以及我们自己的
事故报告了。再补充聊聊评论区比较热门的两点。以上这些都是大家摸鱼多年在面对运维时可能见识过的场景，草台班子确实很草台，但没办法，这就是大型
互联网应用的宿命，熵增是不可避免的。另外还有件很有趣的事，对于工具类、系统类应用（像Oracle数据库、Visual Studio，甚至各种库），它们也存在不少屎山代码，但这类应用出问题的概率低很多，因为守着它们的不是运维人员，而是大量的单元测试。
互联网应用由于要快速迭代，单元测试的数量显然比这些工具类、系统类应用少。最后补充一个很黑色幽默的小插曲：刚刚
阿里云的电销人员打电话给我推荐
阿里云套餐，还附带各种折扣。
