技术保障这个话题老套极了，但不幸的是，截止当前，技术保障仍然是一个人力密集 + 知识密集 + 资产密集同时存在的领域，大白话说，就是既要堆人，也吃经验，还靠装备，缺一不可。

而中国的互联网，更是处于全球数一数二的位置，已经渗透到了生活的方方面面，接二连三的这些故障，让整个社会都开始关注幕后的技术保障工作的重要性。大型互联网平台复杂度是非常高的，体现在：

过去的几年里，「降本增效」成为了 IT 圈的政治正确，在执行的过程中，因为一些理解的“片面性”，导致执行变了味，走了样，最后容易变成一地鸡毛。

降本增效，要讲科学，投入产出要拉长时间段来评估（比如看3到5年的整体投入产出），切忌只看当下，不顾全局。缩减人员或者下服务器，虽然一下子会节约一笔钱，但是这个动作给用户体验造成影响会有多大、会不会给服务稳定性埋下隐患、一旦服务受损能不能承受得起、会不会一段时间内又需要花费更多的财力物力重建，等等方面需要通盘计算和考虑。

举个笔者曾经参与过的项目，作为反面案例，供大家警醒反思：

在公司内部，经常听到高层口头上喊的都是“稳定性是第一位”。在实际操作的过程中，每当“资源投入”有冲突的时候，「技术保障工作的投入」永远都是可以往后排的那一个，排在“盈利KPI”、“拉新KPI”、“促活KPI”、“开发新功能”等等的后面，知行难合一。

在业务领域，常常讲，要让听得见炮火的人做决策。技术保障工作，也是业务的重要、必备组成部分，一线的技术专家，却往往很难发出声音，比如项目deadline，永远是倒排，只有接受的份；比如能否投入固定比例的资源用于优化基础能力以及还技术债务，总是会被拍死；技术保障的工程师想晋升，也很难被倡导业务价值的晋升观念所认可，而出现一次大故障，却可以断送掉之前所有的努力。

再举一个笔者参与过的项目，再次供大家警醒反思：

对技术专家们的价值，不能客观地评价。这几年各行各业或多或少遇到了增长的瓶颈，以往发展能够掩盖大多数问题。在当下的情况，很多公司开始缩减技术人员规模。公司里，搞技术保障的团队，都属于幕后团队，基本从未走上过“前台”，价值也不容易被看到，工作不易被理解。平时不出故障，不显眼，要是出了故障，又太显眼，里外不讨好，因此在“人员缩减”中，首当其冲。

这些老师傅们，主打一个「对系统熟悉」，知道哪里有坑，从而能少掉坑，老师傅们的责任心都很强，今天的坑不填，明天掉坑里的只会是自己，在不断填坑中前进，用时间换空间。根据经验数据，当技术保障团队的老师傅们离开后的一段时间内，必定会出现大故障，且往往都是接二连三的，直到新接手的工程师们变成老师傅。因此，公司应该致力于创造好的大环境，制定好规则和激励计划，让专业的人做专业的事，做专做深。让老师傅们能有空间做长期正确的决策，成为公司的宝贵资产和重要竞争力。

每当出了大故障之后，很多公司内部一定会先对某个技术负责人，再加上某几个一线技术人员，杀一儆百，然后发起一场“运动式的技术保障攻坚项目”。这个阶段，虽然是靠很高的代价换来的，但却是真正做事的技术人员最欣慰的日子，能够把以往想做、得做的事情，趁机完成。因为大家知道，这阵风过后，技术故障工作又会变得无人问津，直到下一个倒霉蛋再出现，但谁又能保障自己不是那个倒霉蛋呢。

如果不能回归到「专家领导专家」的工作方式，让专业的人领导技术保障工作，充分的授权，长远做规划，做长期正确的事情，那么接力跑还将继续。

最后，希望互联网能够再次回到之前那个百家争鸣、欣欣向荣、活力四射的年代。