据在滴滴的朋友描述，这次事故不仅仅用户端滴滴客户端、企业滴滴客户端、共享单车无法使用，公司内部系统都崩了，研发和运维排查解决问题搞了一夜，临近年终，滴滴的小伙伴绩效和年终奖估计要腰斩了。
技术团队的相关人员都知道现在这种大规模的公司，都使用分布式服务、去中心化，目的就是之一就是避免一个服务有问题导致所有服务都不可用，然后这次依然接近所有服务不可用，应该是底层基础设施出现问题了，像滴滴这种复杂的LBS(基于定位服务)服务，如果底层出现问题很难排查修复，篇幅原因具体技术细节不聊，这件事的底层逻辑本质上还是出现在人身上。
阿里云服务出现问题才没多久，滴滴整个服务崩了，巧的是就在前一段时间被爆出，阿里云和滴滴先后大量裁员，据在滴滴的朋友描述：裁员前五六个人负责一个项目，裁员后只有一两个人负责，留下的员工不仅要做新需求还要维护线上正使用的功能，长此以往出问题是必然，技术和代码是一项很严肃的事，有一点漏洞就有可能造成公司整个内部服务不可用。
最近这两年互联网领域裁员裁上瘾了，不管该不该裁，能不能裁只管执行，目的就是降本增效，这次滴滴真的成降本增“笑”了，还损失4个亿的代价，这还是明面上的账，互联网公司一旦有线上事故，都要复盘总结，接下来一个月滴滴各个团队都要忙碌总结经验和甩锅的事，增加的效率呢？这是隐蔽的水下账目。
跟京东的一个同事聊天，京东也经历几轮裁员，每个项目组留下一两个人，其他人员以外包的形式再招，朋友头皮发麻，感觉整个人都要抑郁了，招来了外包人员有两个无法解决的问题：一、熟悉项目需要很长时间，不能短期内上手做需求，即使熟悉了每在老项目上改动一点都要紧张一阵子，有可能直接导致严重问题。二、由于预算成本问题，招不来懂底层技术的人比如懂并发编程、性能优化、生产实际问题处理经验的人员，所以公司内部这些高并发大数据的项目出现问题都解决不了。
其实，在大厂工作过的人员都知道，裁员的预算都是非技术领域的领导层或人事部门直接决定，他们甚至公司的架构都不知道就敢对技术团队直接开刀，预算一定，HR高高在上的就开始大刀阔斧的通知被裁的同学，直到现在他们都没有意识到裁掉的不是技术人员，裁掉的是服务的安全保障。人员都不稳定，还想系统稳定？
环境不好降本增效没有错，但裁员也要慎重一些，有计划的裁，了解了每个部门甚至每个岗位的离开对公司项目构成的潜在风险，做到谁去谈谁负责不过分，给人事部门一些责任上的压力。
不管公司、团队还是领导在顺风局获取的成果不一定靠得住，有时代的红利，也有市场的红利，还有平台红利。在逆风局还能稳扎稳打，冷静沉着的应对，才是真正能力的体现。
