写在前面的话：

疫情结束一年多了，本周起北京的最低气温都在零度以上了，我们度过了第一个没有口罩的冬天，感谢政府与医护人员三年来不计生死的付出，没有你们就没有我们的健康与安全。

新冠疫情期间，政府提供了各式工具与政策来保障国民的安全，核酸检测系统就是其中之一，我们每日做核酸并上传数据至国家卫健委，国家卫健委根据汇总的数据做出各类防疫决策，核酸系统在防疫战斗中起了重大作用，本人也有幸曾参与其中。不同的省份或城市使用的核酸系统各不相同，本文所述内容（若无特别说明）均指北京核酸检测系统，与其他省份或地市的核酸系统无关。

为防止泄密及一些合规问题，文中会把一些敏感信息进行加密转换。例如：假设某软件真实使用的版本是2.0，但本文会故意说成是1.0或者3.0，而数字方面则会把20说成16或者97这种同一量级的数字，不会出现把80说成800万这种明显存在量级差的情况。

现在正文开始：

我们都知道，一个技术团队的产出优秀与否，通常由技术水平与管理水平决定，技术水平的高低决定了代码质量的高低，而管理水平的好坏则决定了技术团队能否发挥出他们的能力。本文也将从这两个方向展开来描述。

先从技术视角看

核酸检测系统本质上就是一套管理系统，实现各种数据的增删改查及数据统计分析，很多刚毕业新手研发工程师都能设计出80%的通用功能，从技术上看这种系统是非常简单的，但是北京的核酸系统动不动就挂，导致大家在大街上总得排队等待，那么系统故障的原因是什么呢？其实故障的原因并没有你们想象的那么复杂，原因仅仅是因为，线上的环境没有任何优化，各种低级错误相互作用，其环境配置堪比小白选手的个人测试机，系统不挂才怪呢。

北京市核酸检测系统由某公司(不是东软，后面会说明)使用xxx语言开发，使用了mongodb与redis等数据库，业务部署在k8s内，配套的各种辅助系统例如elk，kafka，prometheus, hadoop等等也都有，和绝大部分公司的技术栈都差不多，还有很多其他中间件和数据库由于与本文所述的各类故障无关，故不赘述。

北京核酸系统的主数据库为mongodb，采用3台机器的副本集模式，这是最基础的用法，虽然未使用分片等技术，但对于核酸系统来说应该也足够了，因为北京核酸系统虽然是给2000多万人使用的，但其并发量的上限却是固定的，街上有多少个核酸亭，最大并发就是多少，这是理论上的最大并发，而实际上，每个人做一次核酸需要15-30秒，哪怕我们按10秒计算，假设整个北京有2万个核酸检测亭，那么平均并发量就是2000左右，最极端的情况才会到2万，也就是所有检测亭的工作人员在同一瞬间同时点击，但这种概率极低，况且就算所有检测亭都同时点击了，那么最大并发也只是达到了核酸亭的数字，并不会导致很高的并发，所以本系统看着访问量巨大，但实际他的负载是很小的，2022年年初北京某某区做过几次全员大规模核酸检测，当时系统CPU使用率的峰值是7%左右，内存是百分之十几，注意是峰值，不是均值，峰值才7%，可见系统负载是多么地低，故资源不足也绝对不是故障的原因，各种故障都是代码和配置造成的，下面就细说一下该系统在使用中存在过的大量低级错误，大家看看自己的公司是否也存在同样的错误。若有就尽快改正，若没有则可以根据本文来吸取一些经验教训。

首先是基础配置篇：

1. 系统没有任何优化，有的机器甚至执行ulimit -n看见的是1024，震惊吗？

2. 所有数据库和中间件的配置参数和官方源码里的几乎一样，基本没有优化。

3. 所有服务都是手动运行的，未配置开机自启，导致只要系统重启服务就挂。

4. 只有k8s内有prometheus监控了集群一些状态，其他监控一个没有，磁盘满了也不知道。

5. 2021年曾发生过k8s默认的1年期证书到期未更换的事件，导致了一次大规模故障。

6. 部分机器只利用了20G的系统盘，2T的数据盘则是闲置状态，文件系统都还没做。

7. 操作系统没有做时间同步，每台机器的时间都不一样，误差最大有好几秒。

其次，我们先看主数据库MongoDB，低级错误很多，我简单列几个：

低级错误1：

代码直连MongoDB的3个节点，无读写分离，主库理论上承担了1/3的读流量。

低级错误2：

MongoDB中部分表竟然没有索引，曾经有个表在1小时内被全表扫描了上百万次，进而导致了整个数据库响应超时，业务功能全卡死。

低级错误3：

数据库磁盘是普通机械盘，并未使用SSD，且从节点过少，完全撑不住I/O

低级错误4：

MongoDB的配置文件几乎是官方默认的参数，没有任何优化。

低级错误5：

没有进行合理的分表，部分表过大，虽然有索引，但在大量访问时依然影响性能。虽然做核酸的群众造成的访问量不大，但系统后台有大量的报表计算任务，这些任务也会频繁读表。

现在，我们再来看Redis库，低级错误更多：

低级错误1：

部署路径混乱，磁盘上存在以下多种不同的路径：

/home/work/redis-3.0.0

/home/work/redis-4.0.0

/home/work/redis-5.0.0-cluster

/home/work/redis-6.0.0-cluster

这些路径都存在，里面都是redis的源代码，真正使用的版本是以上路径之一，但又不统一。

啥叫不统一？举个例子：3台机器真正使用的路径分别是：

/home/work/redis-3.0.0/src/redis-server

/home/work/redis-3.0.0/src/redis-server

/home/work/redis-5.0.0-cluster/src/redis-server

这就叫不统一，看懂了吗？

每台机器都有所有目录，但实际使用的版本和路径竟然不一样。

2022年年初的一天晚上，一台物理机因硬件故障导致若干台虚拟机重启，重启后值班运维反馈redis重启后数据都没了，经过排查后才发现是以上原因造成的。由于所有进程都是在命令行手动运行的方式启动的，有的是在/root目录下执行/home/work/redis-3.0.0/src/redis-server回车，有的是在/home/work/redis-3.0.0/src/目录下执行./redis-server回车，所以当你执行ps aux | grep redis-server时，看见的进程名是不同的，带路径的还好，不带路径的完全就不知道启动的是哪个目录里的哪个版本了，且服务未设置开机自启，于是乎，系统重启后，值班运维发现未重启的两台机器的redis进程都是/home/work/redis-3.0.0/src/redis-server，于是在重启的那台也执行了这个命令，最终当然就没数据了，因为第三台机器的正确路径是/home/work/redis-5.0.0-cluster/src/redis-server，和前两台并不一致。事后我们做过统计，排除那些我们知道的肯定未使用的源代码版本的目录，剩余目录共有8192种组合，运维在不知正确路径的情况下，成功恢复正确进程的概率只有8192分之1，那天值夜班的是刚毕业不久的初级运维，你别指望他能一次找对。

低级错误2：

Redis分片功能使用不当，该系统使用了某技术方案实现了分片功能，所以理论上某个key只会存在于某一个分片中，但不知道是什么时候开始，有些key在多个分片中都存在了，我猜测最可能的原因是，从某时间点开始，某个研发错误地连接了redis的某个IP，并未连接分片的路由IP，导致很多key意外地直接写入了某个不该写入的分片内，而不是通过路由的方式进入到这个分片，而若使用路由的方式，则其hash值并不会落到这个分片内，于是乎，此版本的代码会发现，向redis内写数据会成功，但是写库成功后，网页内却显示不出来，那是因为数据被写入了错误的分片，而通过路由读取时读的不是这个分片，所以才读不到。最后代码只能把所有分片都连一遍，每个分片都存一份数据，以上原因是猜的，不一定对，只是从现象上来看是这样的。

低级错误3：

因错误2导致删数据时删不全，通过路由分片删数据只会删除正确的分片内的数据，而由于错误用法造成的垃圾数据则会被留在其他分片内无法被删除，导致redis内的垃圾数据越堆积越多。

低级错误4：

Redis定位不明确，内存型数据库适用于当缓存，而该开发商则错误地把它当成了持久化存储来使用，在使用过程中，核酸系统要求redis是不能挂的，一旦redis故障系统将不可用，人为引入了隐患点。

低级错误5：

Redis存放的数据太混乱，例如大量二维码图片被存到了redis内，导致内存使用率极高。

低级错误6：

持久化策略未进行优化，生产环境使用的是redis的默认策略，即：

save 900 1

save 300 10

save 60 10000

由于redis的写操作很多，巨多，天量级的多，故以上配置导致了主库一直在不停地dump内存到rdb文件，再加上库中有大量垃圾数据，单master处理的数据已经将近25G，进而导致了主库bgsave和从库psync的速度极慢。最终效果是从库无法在主库下次bgsave之前完成数据传输，而主库此时依然在不停地写入，repl-backlog-size很快耗尽，于是主从同步失败，slave重新发起psync，循环往复，从库永远追不上主库，此时的redis除了未影响业务以外，基本已经千疮百孔，隐患爆表了，任何一个小故障都会引起灾难性的后果。

低级错误7：

Redis的存储也是机械硬盘，大量的写入导致不停地bgsave，进一步影响了磁盘IO，主库落盘速度很慢，再读出来同步给slave也慢。

最后，我们再来看k8s篇：

低级错误1：

所有的node节点均使用同一个nas做为后端存储（做成了pv），一旦此nas故障，所有node/worker节点将全部不可用，高可用机制失效。

低级错误2：

做为整个集群唯一PV的NAS存储，好像是普通机械盘，不是SSD，也可能记错了，我印象中是普通盘。

低级错误3：

所有deployment都向这个pv内写日志，IO向一个点集结，不卡死才怪。

低级错误4：

同一条日志写了3份，第一份是stdout，由于是在pod内，故此份日志最终进了上面那个唯一的PV，第二份日志是写入了“本地磁盘”，也由于是在pod内，所以这里使用的本地磁盘，最终依然是上面那个pv，第三份日志写入了日志kafka内，logstash会作为消费端，将日志kafka内的数据转储到ElasticSearch内，但是，该日志kafka使用的磁盘也是这个nas，所以，同一条日志一共存了3份，而这3份日志却全部存储在了同一个nas内。

低级错误5：

这个其实不算k8s的，算代码端的，具体错误是，deployment的yaml文件中配置的log级别不生效，代码里写死了debug级别，无论deployment的yaml里配了什么，最终都是debug，而每一条debug日志都会被存3份，这3份又写入了同一个nas，几十台k8s node节点又在同时使用同一个nas，你能想到后果吗？我猜你想到了。

低级错误6：

deployment未配置反亲和，由于经常发版升级，所以很多服务经常会跑到同一个node节点里，造成了单节点场景，虽然未发生因硬件故障导致所有pod同时故障的情况，但这种隐患是一直存在的。

低级错误7：

代码连接statefulset时，并未使用service_name.namespace，而是把所有pod的地址写进去，这导致了一旦某个pod挂了，服务就跟着挂了，集群扩容和缩容也会影响业务服务，每次因资源不足而扩容或迁移时，都有一堆服务需要改配置然后重启，人为引入了隐患点。

以上便是os/mongodb/redis/k8s等组件在使用中真实存在过的问题，还有很多其他低级错误，由于未造成什么影响用户的故障，所以本文就不列举了，根据以上这些，相信你也能猜到线上环境是个什么状态。

也许有人想问，既然你知道这么多低级错误，为什么不处理呢？答案也很简单，这些低级错误都是我们入职前就存在的，而入职时的那段时间正是开始频繁大规模做全员核酸的时段，所以这些隐患被一个个触发，我们复盘找故障原因的速度一直赶不上故障发生的速度，以上所有结论都是事后复盘所得，当时根本没时间去排查，运维团队已经被各种已经发生的P0故障把时间耗尽了。

下面我们就以真实案例复盘一下几次比较大的故障，看看我们从中能学到什么：

真实故障一：

2022年年初某天夜里，夜班同事反馈系统大规模故障，原因未知。

经排查，故障原因系某物理机断电导致，9台左右的虚拟机发生重启，其中大概两三台左右的机器在重启后服务未自启，都是未配置导致，其中就包括上面说过的一台redis节点，于是造成了系统故障，由于当时没有什么监控，连redis进程没了都不知道，最终只能由研发同事一点点看日志，最终发现是redis连不上，进程没了，经检查发现是因为这台机器重启了，然后我们又立刻检查所有其他服务器防止类似情况发生，结果不查不知道，一查吓一跳，我们惊讶地发现有9台机器在同一时间发生了重启，随后运维人员联系政务云，最终确认是物理机故障导致。

这个故障暴漏了太多的问题，最大的问题就是没有监控和没有开机自启，以至发生故障后根本没人知道，业务方反馈以后技术团队才后知后觉。暴漏的第二个问题就是，连开机自启这种最基本的配置都没有，技术欠缺太多。这次故障虽然是硬件故障导致的，该开发商并非第一责任人，但也不表示完全无责，这么多低级的错误，哪怕少一个，只要让故障的闭环不成立，也不至于发生影响业务的故障，好在这次故障是发生在后半夜，大规模核酸检测已停，只有少量医院/机场等场所在24小时使用，但也属于重大的P0级故障了。不过呢，该企业并未向卫健委承认错误，而是把责任完全推给了政务云，说如果你们硬件不挂也不至于这样，其实这种理由是说不通的，硬件不可能永远正常，质量再好也有坏掉的一天，使用者不应指望硬件永远不坏，自己水平菜就是菜，推卸责任更能说明自己菜，不过这次故障最终应该是政务云背锅了，因为有件事他们的确做的不对，那就是，硬件故障后没有任何通知与通报，我方在人工检查了所有服务器后，发现9台机器在同一个时间点重启，然后才怀疑是硬件问题导致，政务云后来也提供了最终受影响的机器列表，IP地址与我方统计的完全一致，这属于政务云未尽到监控与告知义务，于是这个大锅就背上了，政务云有点责任，但也不至于承担100%的责任，有点冤。

真实故障二：

2022年年初某天早上9点左右，北京某区正在做全员大规模核酸检测，系统越来越卡，直到某刻，系统彻底无法使用。

经事后排查，造成此次故障的原因，简直是，我先骂会街，！@##￥&#Y￥&#@。故障由多个低级错误联合造成，其中任何一个错误只要不发生，故障就不会发生，但最终他就是发生了。

此次故障的引爆点是redis，当时代码到redis的连接池的数量设置的很低，只有8个还是6个来着，要么是20，记不清了，总之是个很小的数字，系统负载较低时是没什么问题的，而一旦使用量上升，连接池耗尽，新的TCP连接就将无法建立，只能等待旧连接断开，对外表现就是系统卡顿一直转圈。

当然了，故障是redis引发的这个结论，是事后排查和复盘时才知道的，当时并不知道，对于当时的情况，唯一的方法就是扩容加pod，扩容操作也的确有用，每次扩几个pod，系统负载都会降低一点，卡顿转圈也会短暂消失。但是扩到最后，系统不但未稳定下来，最终反而导致彻底宕机，那导致故障的原因到底是什么呢？

其实前面列低级错误列表时已经说过了，由于业务代码里把日志级别写死了是debug，当pod较少时，产生的日志量未达到磁盘IO的上限，系统还能运行。而当pod扩容时，产生的日志则成倍地增长，同一份日志又因代码缺陷导致记录了3遍，而k8s所有node节点又同时使用同一个nas做pv，于是，当pod数超过某个临界值时，该nas的IO处理能力再也无法满足日志的产生量，于是nas的io卡死，进而导致k8s所有node节点的数据盘卡死，df没反应知道是啥情况吧? 于是，整个k8s集群失去响应，业务完全挂掉，于是P0级故障再次发生了。

我们现在再以上帝视角复盘当时的操作，故障有可能避免吗？根据复盘结论来看，没有任何办法，当时是只能扩容，不扩立刻就挂，扩了能撑一会，撑一会再挂，所以扩容能延后故障的时间点，但却无法避免故障最终的发生。

事后经信局问责，询问故障的原因，并表示当天的检测量低于前几天的那一轮大规模检测，而上一轮检测那天系统并未挂掉，为什么这次检测量变小了反而挂了呢。我不知道最终公司是怎么解释的，但无论如何解释，公司给出的理由都是不成立的，因为即便是到了今天，我这个当时的亲历者、亲自排查和处理的故障的人，都无法给出准确的故障原因，我只能根据当时服务器的现象猜测，大概可能的原因是并发量破前高造成的，前面我说过，假设有2万个检测亭，每个人做核酸耗时10秒的场景下，理论的平均并发值是2000，而实际中有可能是1000，也可能是5000，最大是2万，第一次做全区大规模时，可能全天的最大并发并不大，工作人员的点击操作比较平均，而发生故障的那天，很可能就是大家多次在同一时间点同时点击，造成了并发瞬间升高，所以虽然检测量变小了，但并发却是升高了的，当然了，这个原因也只是我根据当时的现象猜测的，不一定准，但感觉也八九不离十，这就和飞机失事后没有黑匣子佐证的情况下，工程师只能根据各种零件的损坏情况来猜测原因一样，最终的结论无限于接近真相，但永远不等于真相。

也许有人想问，瞬时并发升高导致了卡顿，大家只要不点了，系统不就可以一点点恢复过来了吗？为什么会出现不停的扩容却不停地挂的场景呢？是啊，确实如此，但为什么它就挂了呢？答案也简单，你想象一下当你访问某个网站打不开时你会怎样？相信大家都会刷新重试吧？所以，一旦系统开始变卡，访问量不但不会降低，反而会因为所有人都在重试导致瞬时并发继续升高，每次扩容都能承担一部分新增的重试请求，但毕竟检测亭太多了，扩容的量远远比不上大家点击的量，所以这个过程也就变成了不可逆，这个场景和被ddos攻击很相似。

这次故障后，该区再也没做全员大规模核酸检测，由于该公司当时还负责北京冬奥会的赛事保障工作，为避免冬奥村受到影响，当时的北京副市长殷勇（2023年升任了市长）做出决策，把北京市社会面的核酸检测系统临时更换为东软的核酸检测系统，而该企业的核酸系统则全力保障冬奥会，本是为2000多万人设计的系统，最终却只给了冬奥村的20万人使用，后来该系统经过半年时间的不断改进与升级，解决掉了曾经存在过的大部分隐患，但直至2022年12月7日疫情防控全面开放，北京的核酸系统也再也没有切换回去，东软的系统被一直使用到了最后。

真实故障三：

这个故障其实我印象有点模糊了，也是2022年年初的事情，忘记了是由于数据库的什么事情，导致了系统特别慢，但是没挂，没影响用户。当时CEO不分青红皂白就要求扩容，运维这边表示肯定不是资源不足造成的，因为系统的使用率并不高，一味地扩容没意义，且扩容操作会占用运维的时间，导致我们没时间真正去排查错误，但是CEO强制要求立刻扩，让我们找政务云要机器，当时也是疫情最严重的时候，所以只要我们申请新机器政务云就会给，至于成本和使用率什么的不在他们的考虑范围之内，毕竟若是因为资源不足导致系统挂了，他们是担不起这个责任的，所以他们立刻就给腾挪了机器，我记得他们好像还紧急从其他地方调了机器，因为当时的机房资源几乎快要耗尽了，我们拿到新机器后就对数据库进行了扩容，而扩容完成后，数据就开始混乱了，故障发生，那么故障的原因是什么呢？

答案也很简单，那就是，政务云给的新机器，系统时间和北京时间差了15分钟左右，不记得是快15分钟还是慢15分钟了，总之就是时间差异很大，这也很好理解，可能是虚拟机没有和硬件时钟进行同步，没做这个确实不应该，但也不算责任，毕竟配置时间同步是使用方的事情，就像你的手表没电了，换了电池以后时间肯定停留在了停电前的那个时刻，这时候你有义务自己把时间校对正确，而不是让卖手表的人过来给你调。而该核酸系统的开发公司，当时自己并未做这个事情，拿到机器后，装了mongodb后就开始将新节点加入副本集，最终数据开始大规模混乱，印象中公司当时临时招了很多外包人员，把办公室所有工位及所有会议室都坐满了，很多工位都是一个位置坐俩人，一堆人24小时不停地俢数据，数据好像错乱了好几百万条，都需要一点点人工改回来。

现在我们复盘当时的操作，如果CEO不盲目地要求乱扩容，也不至于发生后面的故障和数据错乱，这个故障完全就是瞎指挥造成的，没有其他原因。但运维这边也有失误，那就是没有同步时间，不过当时连监控都没有，生产环境和你个人本地的开发机没太大区别，扩容的执行人又是个刚毕业不久的新手，想不到这些步骤也很正常。

故障恢复后，我亲眼看见了CEO垂头丧气地坐在运维工区边上，耷拉个脑袋，眼角向下，还用很委屈的语气说，我欠考虑了，要是不扩容就好了，这不是原话，原话我记不清了，但大致是这个意思，该企业的CEO表情很丰富，有的人喜怒哀乐不行于色，而该CEO则相反，是喜是忧一看便知，说实话，我当时感觉他有点可怜，很同情以及非常能体会到他的感受，但事情已经发生了，后悔也没什么用了，我们只能尽快把各种缺失的监控、优化、时间同步、开机自启等基础事情做好，确保以后别再出现这种低级错误，这是我们权利范围内能做的最大的改进了，事实上我们后来也的确做到了，当时的我们也都刚入职，对公司尚无任何不满的情绪，当时真的是尽全力付出想要把系统做好的，但历史遗留问题实在是太多了，真的没办法。

至此，三次比较大的故障都复盘结束了，还有大量的小故障数不胜数，由于没影响用户所以本文也没必要讲述。综合来看，除了第三次是CEO要求下，人为导致的故障以外，其他所有的隐患点，低级错误等，都是能力欠缺导致，我曾经这样跟人描述过当时的场景，凡是运维需要做的事情，凡是你能想到的，我们都没有，没错，就是都没有，此时的我们刚入职不到两个月，每天都在应急救火，这个没修好呢那个又挂了，每天都是疲于奔命的状态，根本没时间进行检查和改进，上述所有的故障也都是那个时间段发生的，后来当我们有时间做这些基础工作以后，这类故障就再也没发生过，直到一年多以后我们一一离职，也再没发生过这样的故障。

额外说一下我们为什么不加班处理呢？不是不加班，是天天加班，每周工作7天，每天在公司15小时以上，连除夕夜都是在公司度过的，每天晚上回家只能不连续地睡3-4个小时，因为到家后（经常夜里一两点）有一批人可能会打电话，第二天早上5点多又有另一拨人打电话，一年上班365天，最累的一周累计只睡了10个小时，睡觉也不是睡，而是困晕过去了躺在桌上，过一会突然惊醒以后才发现自己睡着了，然后再根据“昏迷”前的时间是几点来计算自己“睡”了多久，最终，那一周我一共睡了不到10小时，一周没回家，所以不是不加班处理，而是我们团队当时真的已经到了生理极限了，我个人的身体也在那个时候熬出了严重的问题，体重飙涨20斤，2023年离职后在家休养了半年没上班，这期间至少有15个夜晚一夜没睡，不是不困，而是身体原因导致无法入睡，我个人至今都在为当时身体透支而持续付出健康成本，中药累计喝了上百斤了，其他同事由于是普通岗，没有我负责的事情多，所以比我轻松些，但也好不到哪去。

技术复盘就说这些吧，读完了这些，您有何收获呢？我简单总结如下：

1. 操作系统上线使用前，必须进行必要的处理与优化。

2. 磁盘的分区与挂载，时间的同步，都必须处理成功才能交付使用。

3. 各种数据库与中间件必须要进行必要的参数优化。

4. 数据库与中间件必须根据使用场景设计不同的架构，不能直接使用官方默认配置。

5. 所有系统都必须进行高可用配置，不可以存在单点隐患。

6. 技术的工作让技术人去处理，外行不要瞎指挥。

7. 数据库使用前，要正确评估IOPS，QPS等数据，不能盲目上线使用。

8. 什么功能的软件就做什么用，不能乱用（这个是指在redis里存二维码导致内存暴增的事）

9. 业务功能上线前要进行必要的功能测试与压力测试，不能把生产环境当测试。

我随便列了这么几点，你还有哪些补充吗？

现在技术视角聊完了，我们再从管理的视角来看看为什么会有这么多奇葩的情况存在吧。

技术界有句至理名言，那就是，凡是技术问题，都能用技术解决，没有什么技术瓶颈是无法解决的，而若造成了技术困境，通常都是管理水平不足造成的，那么该企业在管理上有哪些不足呢？

首先，高管内斗。这是起因。公司最初的CTO和CDO因一些纠纷被CEO踢走出局了，直接将其从钉钉内移除，关闭所有账号，后来CDO换人了，CTO一直空缺到今天。当时公司为不让两人来公司维权，曾组织大量男员工在办公楼所有的出入口进行堵截，包括所有步行梯，电梯，货梯，负一楼食堂，负二层和负三层车库，所有门口都有人进行看守，无论谁发现他们接近，都要立刻在群里通报他们的位置，然后公司组织人去阻拦，不让他们进入公司，这是2022年的事情，也就是上面三个故障发生的大概时候，技术负责人都被开了，系统能稳定运行没bug就怪了。公司为了站在道德制高点，还给他们俩起了个名字叫XX团伙还是XX集团来着，其中XX俩字是这俩人的名字各取一字，总之就是极尽诋毁，而他们被挤出局后，新上位的技术负责人则是战斗在内斗第一线的CEO的某嫡系员工，能力极菜，此人好像是CEO的学生，听说好像是，不确定，该企业的CEO以前好像是中科院某所的老师，新上位的这个负责人岗位是技术副总裁，但实际就是个类似”走路的某常见家养宠物”的那个两个字的角色，你们知道我说的是哪两个字吧？在这种背景下上位的人，你觉得他的水平能高到哪去。该企业的知乎内有大量的前员工的爆料，里面痛斥的内容我基本都看过，大部分事情说的都是这个人。但你们现在只能看到一小部分了，因为大部分爆料都被公关删除了，这也是我在本文中不提他们公司名字的原因，以免他们有借口向平台投诉。

第二，不把员工当人。该公司对员工可以说是极度压榨，像牲口一样使唤，有时候还不如牲口，能把人逼疯的那种程度，公司的态度一直是盛气凌人的那种，无论什么事情，都把责任推给员工，今天说这个员工有问题，明天说那个员工有问题，还动不动就发全员公告，内容每次都差不多，说的基本都是某某某员工，在某某工作中，思想不积极，工作不努力，给公司造成了什么什么损失之类的，公司对该员工给与严重警告，望广大员工引以为戒，端正自己的工作态度，积极地为公司奋斗类似的话。最搞笑的是有一次竟然对一个已经离职的员工发通报批评。公司从来不说自己有问题，只要出事那就是员工的问题，曾经知乎里有大量员工的爆料与吐槽，然后公司组织法务给离职员工大批量发律师函，要求他们删除爆料与取消点赞，还在公司内部调查哪个哪个账号可能是谁，然后他的上级要担责，没错，如果你的下属离职后去知乎上吐槽你是要担责受处罚的。该公司一直在防范员工去网上爆料发声，但从来不想为什么每个员工离职后都这样，甚至，很多员工还没离职呢也这样。公司从来不反思自己为什么和每个员工都处不好关系，为什么和每个供应商也都处不好关系。公司还曾经发全员公告，让大家去学习什么是“达克效应”，暗示员工们都有问题，不要自我感觉良好，可我看，最应该学习的反而是公司自己，而不是员工。如果是少数员工对公司有意见，那绝对是那几个员工有问题，现在是几乎所有人都对公司有意见，那还能是员工的问题吗？看看公司有多少仲裁就知道了。

第三，企业无担当，没责任心。和第二点相似，有问题就怪员工，和其他企业合作时也把各种责任推给其他企业，例如技术章节复盘时我们提到了公司把责任推给政务云，该政务云当时确实有点小过错，导致最终背了大锅，我当时一直奇怪，为什么我们有需求找政务云时他们对我们的态度很不友善，爱搭不理的，后来我明白了，我们一直不停地甩锅给他们，他们态度能好才怪呢，2022年3月我去经信局参加了一个核酸相关的会议，第一次实地见到了该政务云的负责人，于是我上去打了个招呼，放低姿态以类似道歉的口吻跟他说我们以后好好合作，一起把防疫系统做好，避免疫情扩散，如果我们有哪些做的不好的地方请您多担待。他的回复也很客气，毕竟是现场面对面，也不至于说酸话和狠话，但是后来也就那样吧，因为我们很快就把政务云从他们家换成了别家，再加上以前替我们背的锅，这无异于在向卫健委说他们不行，我们要把他们换掉，虽然实际我们并未这样表态，但我们的做法已经在暗示这样的观点了。所以呢，他们跟我们不可能有多友好，于是我们技术团队的同事就被坑了，明明是公司惹毛了人家，最终影响的却是我们的工作。

第四，公司为了利益，拿疫情防控当儿戏。最早的核酸系统版本中，好像是某个小程序还是什么功能，页面里面有图片，图片没上CDN，这又暴漏了一个新的技术缺陷，技术章节忘记说了，当时该系统是给云南省使用的，云南人口没有北京多，但是大规模核酸检测时，造成的带宽峰值达到了2G，就是因为几个几百K的图片造成的，而当时版本正在滚动升级，当时技术团队要改成使用CDN，但是CEO却说不上，毕竟上了CDN以后的带宽成本是要我们自己承担的，CEO说把这个压力转给政务云，这个也不是原话，原话记不清了，但原话里绝对有一句把压力转给政务云，这句话我印象极深，CEO当时大致的意思就是北京的核酸系统也这样用，我们不用考虑带宽的事，这些事让政务云负责就行了，他们有义务解决带宽问题，我看得出来当时CEO说的是气话，但我依然吓的立刻去问了政务云他们的总带宽是多少，你想想如果机房带宽被打满导致系统无法使用，最终因未及时检测出阳性患者导致疫情扩散会是什么后果？政务云回复后，我得到的回复是几十G，真实数字我就不说了，总之总带宽远远高于我们的需求，这我才稍微放点心下来，按北京与云南的人口倍数来估算，图片不上CDN带来的带宽最高能到10-15G左右，政务云的总带宽能轻松覆盖这个量，所以我就没说啥，这也属于我在默许公司故意去坑政务云了，不过我反对也没啥用，老板的话大于天，打工人没话语权。所以，后来无论政务云的同事用什么态度跟我们说话，我都没有任何不满的情绪，即便他们想骂我，那也是我们应该承受的，当然这只是举例，他们不可能真的来骂人，我只是表达这个意思，但他们在背后偷偷骂我们肯定是100%的。当然后来我们也没有按坑政务云的方法去做，图片最终还是上了CDN。

第五，为了利益，违规将敏感数据放在公有云上。既然上面提到了云南省核酸检测系统，那我就说几句云南吧，云南全省都在用该企业的核酸系统，河南与山西也有几个城市也在单独用，四川有个自治州刚开始部署，但最终没上线，再就是北京了，该企业的阵地一共就这些，其他城市和省份用的好像都是东软的。云南当时由于没有政务云，这种政务系统又有合规要求，所以该企业一直说自己用的是其他政务云，但实际根本不是，他们用的是某家公有云，所有数据都在公有云上，完全不符合合规要求，更大的隐患是数据库里的敏感信息都没加密，身份证手机号居住地等信息全能直接查到明文，不知道后来改没改。由于该企业没有按要求使用政务云，有一天夜里11点多还紧急拉过一次会讨论怎么向云南卫健委解释，当时参会的同事们说立项时是如何如何向云南卫健委承诺的，设计书是如何如何写的，但是现在云南那边问询了，公司已经没法解释了，谎言瞒不住了，于是开会讨论如何骗云南卫健委，该企业还曾经为了获得投标资格，让员工大批量自费去参加软考，广撒网的方式，只要有人通过了，企业就能得到一些资格。云南的事，最终该企业是找了其他某个政务云帮忙。北京核酸系统更换政务云之后换成了某新的云，所以云南的事情就找了这个云帮忙，该政务云在北京某区的政务云里有些资源，但很少，带宽性能什么的也都不足，无法正式承担业务，所以该企业在该政务云创建了数十台低配服务器，机器功能角色等完全模拟生产环境，但是没流量，不跑真正的业务，目的就是为了应付检查，由于这些事不能外传，对该政务云也只说这是我们的第三号系统，至于具体是什么系统并未告诉他们。该云后来也得到了该企业丰厚的回报，回报是什么呢？该企业与该云还联合负责过另外一个项目，此项目的甲方已将总费用支付给该企业，该企业则应该把机房资源费用支付给该云，但是该企业一直拖着不给，把对方商务心态搞崩了，后来该云的商务直接发了最后通牒，还来了公司，说这是最后一次催款了，如果贵公司依然拒不支付那就只能走法律程序了，还亮出了当时签订的合同，而公司是怎么躲的呢？该云的商务来访时，是让我出面的，我是技术岗，让我去应付对方商务的催款，逗吧？我和该云的商务同事在一个小会议室聊天聊了半个多小时，只有我们俩，然后其他人才姗姗来迟，之后我就离开会议室了，不知道这事他们后来有没有谈崩。再有就是通州区环球影城项目，这又是另一个项目了，也是与合作方闹崩了，甚至我方的员工都与外协人员一起离职，离职时办公电脑等都拒不归还想用于抵薪，事后半年内又多次来公司维权抗议，电梯间经常围满了来维权的人大声喊口号，我们都被通知不准出去。那个合作方后来还做了一个不该做的报复手段，在市里某领导(好像是殷市长)去环球影城视察时，故意修改了后台密码，导致该企业负责的显示大屏变黑屏了还是没内容了之类的，总之就是看不到该看到的数据了。这明显就是故意打击报复，想让他们在市领导面前丢脸，该厂商远程改密码是我们通过查数据库的方式发现的，然后手动将密码改了回来，最终没在市领导面前出丑，但是过了没多久，密码又被改掉了，后来我们做过多次梳理，直到我们都离职了，依然有大量服务器我们没有密码，无法登陆，对方也不可能告诉我们，没删库跑路就已经算仁至义尽了。

第六，外行瞎指挥。前面略微有点跑题。第六点咱们兜回来，该企业在管理上的缺陷还有一个就是外行瞎指挥，前面说的那个靠内斗上位的技术副总裁，自己水平菜不说，还完全不信任自己公司的员工，无论我们提出什么方案他都觉得不靠谱，总要找外援来帮忙，例如redis曾造成过重大的P0故障，所以他从某大厂请了一位专家过来给我们进行“指导”，当时我们忙的要死，前面我说过我们连睡觉都没时间，哪有时间去听别人的分享，我们redis的痛点我们一清二楚，我们自己有解决方案，对我们来说这也不是什么难处理的技术问题，只是需要很多时间而已。结果这位副总裁大人就是不信任我们，非得让我们去听课，还说我们要听劝，结果该专家讲了什么呢？他讲的是他们公司的场景，他们是自己对redis做了二次开发，实现了什么什么功能，我当时就说，他们公司场景跟我们完全不一样，他这种“传授”有什么用呢？我们的redis是不接受丢数据的，而他们的是纯缓存的场景，数据丢了就丢了，丢了以后可以读后端的关系型数据库，我们场景一样吗？用法都不一样，如何借鉴他们的做法？还有，他们用的是自己开发的系统，他们自己开发的内部工具能拿出来给我们使用吗？就算他们老板同意了，谁来给我们部署？后期出故障谁来给我们解决？报错以后网上没有任何文档如何解决？挂了以后没人知道怎么处理，谁负责？等等等等，一堆不现实的想法，该副总裁就是一个字也听不进去，一直就在那让我们好好听人家讲，让我们向人家学习。最终浪费了我们好几个小时的时间，要是不浪费时间，有这功夫我们事情都做完了，可现在却是把故障和隐患丢在一边不处理，反而去听别人讲那些很牛[字母]但我们却用不上的方案，有啥用？纯影响工作，如果这期间redis又挂了怎么办？但无论我们这边如何解释与反对，此人就是不听，还鼓动我的领导让我们过来听分享（说明：我们部门由公司某高官分管，不归该副总裁管，所以他无法直接命令我们），最终该专家分享的经验也是不了了之，因为那个方案除了他们公司以外，没有任何其他公司可使用，毕竟是他们公司内部的工具，又没有开源出来，你让其他企业如何使用？还有就是，若下班后发生了故障，该企业要求员工要立刻出发到公司处理故障，而不是在家里远程解决，即便是P0级的重大故障，也是必须到公司，我们曾抗争过，说就算让我们来公司，那等我们先把故障处理完然后再去公司开会复盘不行吗？非得立刻出发？公司的回复就是不行，必须立刻到公司，如果你没出门，你的电话能被打到没电，这就意味着哪怕是个你只需几秒就能恢复的小故障，你也需要让它一直处于故障的状态，然后去公司处理故障。而公司这么强硬地要求员工立刻到公司去，而不是立刻处理故障，仅仅是因为不相信员工会在家里处理故障，公司的原话是员工在家里有可能不处理故障，但是说成自己在处理故障，所以才会要求员工在故障发生时必须要第一时间出门到公司去，哪怕路上需要1个小时，那也得去公司，公司要求员工必需时刻在眼皮底下、公司能看见的地方。即便当时是疫情最为严重的时候，核酸系统要是挂了，那满大街的上百万的人都要站着排队等待，此刻相信百万大众最期待的就是我们尽快把故障修复，但是对不起，我们正在被电话轰炸要求我们到公司去，你们期待的时候我们很可能堵在去公司的路上呢，但值得庆幸的是，白天时未发生过这类故障，所以没有导致大家在街上等我们，否则当你们今天看见这段话时得气出心脏病来。

第七，技术管理者技术水平太菜。经常出现“我都不知道这个需求是什么我怎么要求你们做”，大概这样的场景，还有就是对技术知识的储备太浅，前面redis的例子是一个，java连接mongodb时如何设置读写分离竟也不知道，kafka只知topic，不知道partition是什么，自然也就没配，redis删数据不知道怎么删，前面说过redis因未使用路由连接，导致各分片内有脏数据，而写代码删除的需求，当时的研发部门搞不定，不会写，最终，这个代码是运维团队写的，你说奇葩不奇葩。那研发为什么不会写呢？因为会的人都被各种原因挤兑离职了，当时连公司全力投入的核酸检测系统的团队都青黄不接了，大量功能没人知道怎么回事，几个月后新入职的技术团队将k8s中的deployment从70多个缩减到了20多个，下线的deployment说明都是无效的，但是没人知道这些服务是做什么的，只是平白在那运行着占用资源，解决各种bug时，也没有任何人知道怎么回事，当时所有靠谱的人几乎都是新入职的，不能说是100%吧，但也占了绝对多数了，上一批人已经都不在了，再加上该企业一直以来对员工的压榨与奴役，导致所有人离职后对公司都是恨之入骨，这也导致了该企业的在职员工无法像其他企业那样找前员工求助和咨询，最后公司只能付费咨询，该企业的技术副总裁每次都是微信直接发2000红包，然后才问问题，注意，是直接甩个红包过去，然后才有脸问问题，在这样的背景下，业务系统能健壮吗？所以，北京核酸系统为什么那么多低级失误？你现在知道了吧。2022年年初的时候，有次有个bug解决不了，在职的研发基本都是新入职的，谁也不知道怎么回事，只能找离职员工问，但是那次要找的那个员工没时间，已经在新公司上班了，结果公司说，这都什么时候了，这是计较个人得失的时候吗？要找人家过来加班，还说要找公安部门运作一下，把他抓起来关几天，看他帮不帮忙，这是他们CEO的原话，当时好多人在旁边，都看见了和听见了，我也在现场。而公司说这种话的底气来源仅仅是因为有个"公安局反诈系统"的项目合作，仅此而已，然后他们就觉得自己有本事调动公安局去抓一个没违反任何法律的前员工，甚至连任何治安条例都未违反，然后他们就有那个自信可以去抓人坐牢，植物！

第八，没有团队精神，无法组织起团结的队伍。该企业对员工非常不友善，为了防止员工反抗，该企业从入职起就对员工开始各种防范，有事请假都必需写明是什么事，请假去医院还得写清去哪个医院，得了什么病，否则请假不予通过。五一十一前后的几天，很多人会请假凑个小长假，该企业请假时你必须说清楚请这几天假是要去哪，做什么事，否则也是不给假。员工下楼取个奶茶外卖也会被HR跟踪监视然后举报，说员工在工作时间外出，员工的工作与生活都受到了严重的监视。公司的办公软件从钉钉改成企业微信后，连私聊的权限都关了，同事之间由于工作需求要私聊都没办法，只能找领导拉群讨论。员工入职后，试用期会被安排大量任务，员工为了通过试用期只能狂卷，但是他们想不到的是，他们根本过不了试用期，转正答辩时会有各种理由不让你通过，不通过就得离职，然后再招下一批人继续重复这个过程，很多人甚至没熬到答辩就自己辞职了。该企业对员工只有压榨，诋毁，提防，洗脑，动不动就开除，然后还得发公告对其进行抹黑。我的团队的成员也被他们这样开除过好几个人，该企业的转正答辩并不是员工的直属上级定他的去留，而是公司的CEO，技术副总裁，党支部，HR，老板的亲戚等人来评审，你能不能通过试用期和你的能力与产出没有任何关系，能否通过只取决于你表现出来的态度，按他们的话来说，你要有“正确的”价值观，你知道他们心里的正确是啥意思吧？但凡你表现的不符合他们的预期，你就会被打上价值观不正确的标签，然后被迫离职。本人团队内曾有个初级工程师，薪资极低，但他的表现特别好，远远超出其薪资的标准，我对他也特别满意，但转正答辩时，公司就是不让他过，我求情求了至少7次，但最终他还是被迫离职了，把我气得要死，后来他们还对我团队的一名同事进行人身攻击，该企业的技术副总裁说我团队的那个人平时不洗澡，身上有味道他能闻到，留着影响公司，所以试用期不给过，服了，他平时就坐我附近，我是从来没闻到过，这个副总裁和我们中间隔了好几排人呢，狗鼻子吗？

第九，对外虚假宣传。导致新员工入职后心里落差极大，他们在boss直聘里写的公司福利大部分是假的或者言过其词，等员工入职后才发现上当了，再加上那个副总裁的气质，不开骂反而不正常，该技术副总裁还找过我抱怨说：“我新招的人，刚入职就骂我，而且人还是我招来的，他是不是有病？”，而我想说的是，你看你做的那些事，被骂难道不应该吗？为什么我团队的人没人骂我呢，所以，该公司的员工离职率极高，流动非常大，这也进一步导致了产品不稳定，因为人总换，流水式的人接替开发，系统好得了吗？他们对外还总宣传说自己的系统怎么怎么牛，从未发生“丢人丢管”，但实际则是经常丢，技术章节说过同一份日志被记录了3次，就是因为经常丢人丢管，所以他们为了以防万一，把日志写了多份，因为丢失的数据可以从日志里找到，最终修复成功，也实现了他们所说的不丢一人不丢一管，但这真是算没丢吗？还有就是他们一直在大肆宣传自己的技术怎么怎么牛，但实际呢，呵呵，反正能骗一波是一波，总会有不了解公司情况的新韭菜一批一批地入职，公司可以无限使用试用期员工完成业务系统的开发。

第十，赏罚不明。奖励很少，处罚为主。而且各种制度与做法都是以处罚和扣工资为目的。其做法总结起来就是：大功小赏，小功不赏，没错找茬，小错重罚，中错开除，大错没机会犯，中错时已被开除。无论你在公司做了多大的贡献，公司都会当作没看见，大量的人转正答辩都无法通过，而能通过的人，年终总结也一样会被贬的一文不值，2023年年初进行2022年的年终总结时，CEO对我们在2022年做的巨大贡献不闻不问，只说我们产出不够，让我们回去思考能为公司做什么，还有个岗位的同事甚至都还没讲呢就被定性了说不合格，然后年终总结会就中途停了。年度考核时，我们团队被划到了该技术副总裁名下，原本我们和他是平级，现在变成了他的下级，于是他就开始疯狂报复，我本人的考核，他直接说了句我对你不满意，然后给我打了个全公司最低分，绩效等级D，这是唯一一个年终奖金额是0的等级，他给了我，然后还口口声声说这是为我好，说“我这是在帮助你成长，你以后要想在管理方面有所进步，就要怎样怎样之类的”，把“又当又立”表现的淋漓尽致，前面提到的他抱怨他招的人刚入职就骂他也是这时候说的，然后又问到了我平时总买吃的和奶茶什么的给我团队成员的事，说到我和团队成员关系都很好，然后他又开始疯狂暗示让我平时也请他，他跟我说：“你要是找我说：冰哥，我给你买了奶茶，那我也会很高兴啊”，我当时真的是感觉恶心至极，然后他还让我对我团队的人进行处罚，说这是在帮助我提高我的管理能力。那天的面谈聊了将近两个小时，他一直不肯结束，一直不停地疯狂PUA和给我洗脑，后来我不想浪费时间了，就说对对对，你说的都对，都听你的，以后你说啥就是啥，你说罚谁就罚谁，我实在是忍不了了，太恶心了。之后又过了一两个月，每天都各种挑刺找茬，短短几个月，我团队的人就要走没了，后来我也就离职走人了。冬奥会时期全体员工都疯狂加班，本人更是每天在公司15小时以上，当时公司承诺以后会给大家奖励，但是等繁忙时期度过后，公司觉得大家没什么利用价值了，就把很多人用各种理由或开除或挤兑走，典型的卸磨杀驴，兔死狗烹，鸟尽弓藏，而他们做这些事情的时候，那些未离职的人是都看在眼里的，所以谁还敢把事情做的很好，做完了就得被开除，还要被诋毁成价值观不正确，即便离职很久都要被不停地翻出来做“反面例子”，最惨的是曾经的研发负责人，也是为公司做出过巨大贡献，但离职一年多了，还在被拿出来，被骂是XX（经典国骂那俩字），没错，就是那俩字，而且那个副总裁还是笑呵呵地说的，恬不知耻啊。在这样的担忧下，谁会真心付出？

十一，责任划分不明，乱用处罚机制。该企业的产品，无论出什么事情，记录详情时填写的责任人都必需是在职员工，不可以写离职员工，假设某人写了个严重的bug导致大故障了，但是上周他刚好离职了，而你是交接人，那么故障责任人就是你，而不是那个已离职的人，哪怕你是刚入职一周的，那你也是责任人。如果没发生故障时，你由于技术能力强，发现了一个重大的隐患，当你提出这个隐患时，你就必须将其解决，负责人就变成了你，解决好了也没什么奖励，但只要出一点问题，你就是该P0的责任人，这导致了所有人工作时都担惊受怕，能躲则躲，没人敢主动去解决问题或改进系统，毕竟只要出事你名下就会有个P0。该企业对故障也一直都是小题大作，草木皆兵，杯弓蛇影，风声鹤唳，不管啥故障，直接就定级P0，这个也P0，那个也P0，以上种种，导致很多人即便发现了什么也不敢提，所以我们在技术章节说的那么多低级错误，难道真的是因为当时的团队很菜吗？会不会是他们知道这些隐患，只是不敢说出来而已呢？该企业的wiki里记录了一部分的P0故障，但绝大多数都算不上P0，真正的P0只有技术章节里我写的那两次，前两次算，第三次其实也不算，因为第三次只是业务数据乱了，显示的不准而已，系统并没挂。

十二，管理能力弱，领导没主见。前面说过该领导喜欢求外援，不信任自己人，别人说啥都是对的，我们说啥都不对，哪怕外援与我们观点一致，他也觉得别人说的对。这也导致了公司的技术方案不稳定，今天听说了这个就这么干，明天听说了那个就那么干，最被折腾的应该算大数据团队了，最初所有的后台报表计算都是直连的mongodb，后来想要搞大数据，申请了很多台高配的机器，浪费纳税人的钱，但是最终也没做出来，方案一直变，大数据的负责人也在一直变，我印象中大数据团队中没有人通过试用期，所有人全部在答辩结束第二天离职，最终大数据功能肯定也就做不出来了。还有北京核酸系统的架构设计，最初是单云，后来甲方爸爸说了健康宝的做法，说他们可以在两套系统间来回切换，使用A升级B，B升级完毕后使用B，A变回备用，这其实就是蓝绿部署，然后问我们核酸系统如何做，然后，呵呵，你别指望那个副总裁能有什么好见解，最终是我说的，我说我们的资源无法实现这个模式，因为按这种做法，我们的资源需要翻倍，或者将现有资源一分为二，一半使用，另一半做备用，这样才能和健康宝一样，但是按当时的评估，一半资源不够用，资源翻倍的成本无法接受，所以我提了双活的架构，即：选用两家政务云，所有数据库配置成跨云的集群(redis)或副本集(mongodb)，选用第三家政务云部署少量机器做仲裁节点，因为北京政务云有多家厂商负责，他们的机器都在同一栋楼里，所以虽然网络上是隔离的，但是只要开通权限后，内网延迟依然可以在5毫秒以下，和使用一家云没区别，所以我才敢这样设计。数据库跨云后，两家主云分别部署一套应用（k8s等），这样两个云既可以同时使用，也可以单独分别使用，只需要在dns那边改解析就行了，解析到谁谁就是生产，另一个是备用，俩云同时生效就是双活，由于数据库是同一套，所以无论哪边产生的数据，另一个云里都能获取到，按这种方式实现的话，总资源不变，但是业务系统变成了两份，而且是部署在不同的云里，若一家云的平台故障，另一家不会受影响，升级时也可以先升一半，有问题立刻回滚，不会影响用户。大规模核酸检测时，两家云同时启用，这样总资源就是够的，于是就可以实现甲方爸爸的想法了，这是我当时提的方案，后来也按这个做了，但是投入使用后，一直只有一边生效，另一半根本未启用，因为那个副总裁觉得这样不靠谱，不知道他为啥会有这种想法，如果觉得不靠谱当初为啥不反对呢，现在都上线了又开始怀疑这怀疑那了，于是，该系统就一直只用一半云，相当于浪费了一半的资源，但这样也没任何影响，为什么呢？因为早在半年前，北京的核酸系统就已经切换到了东软的系统，该企业的系统一直说要切回来，但直到疫情结束也没切，所以自然无论怎么折腾都不会有人受影响，如果后来真的切回去了，说不定出什么幺蛾子呢，这家企业最不缺的就是作死的行为。

十三，不说了，这样的例子实在是太多了，罄竹难书，说太多可能大家就不仔细看了，此刻的我是在用wps文字写草稿，当前页码已经到了第14页底端了，就先说这么多吧。

综上所述，大家知道为什么北京的核酸检测系统为什么那么XX了吧，由于2022年年初的那几次大故障，很多其他省市对该企业的产品的态度都由接受变成了观望，2022年4-5月左右，时间可能会有误差，CEO曾组织了一个会议，参会人员有公司所有高管及各团队负责人，会议内容是统计公司有多少项目因这几次故障导致尾款收不回来，或者原本计划购买的客户也不买了，当时好像是让财务总监用电脑投影一个个统计的，最终的数字是1.3亿还是1.4亿来着，大概这个数字吧，2022年一季度，公司的损失就是这个数，没赚到就等于损失。之后，该企业也并没有吸取教训，依旧在作，疫情结束后更是日落西山，员工们被用各种方式逼走或开除，仅一个季度的时间，办公室就空了大半，桌上落满了灰尘，本人也是那个时候被逼走的，之后就和所有其他人一样彻底站在公司的对立面了，曾经的热情早已不复存在，对公司的责任感也早已被消磨殆尽，若只是裁员，很多人并不会对公司有多恨，但该企业不只是裁人而已，而是对你各种诋毁，洗脑，逼你认可他们的价值观，你必须赞成他们的所作所为，否则就是无休止地谈话。更可恶的是，他们在做这些事情后，找你谈话都让党支部出面和你聊，明明是他们自己作恶，却非要打着党的旗号，真的是可恶至极。后来党支部的那些员工也和其他人一样被逼走了，并没有因为是党员就能躲过一劫，有的人离职比我还早，最终是谁也没躲过去，除了老板的亲戚。

至此，当初为公司做过各种重大贡献的元老都已不在了，很多人在公司奉献了五六年，最终都被逼走了，什么也没得到。CTO早在我入职的当月就不在了，我也是在入职一年半以后被逼走，所有的其他高管也一个不剩，目前就财务总监还在，其他人都不在了。

截止到目前，该企业尚未破产，听同事说该企业的股东们意识到了投资风险，多方打探企业的情况，多名已离职高管都被找过打探情况，后来CEO以自己经营不善为借口应付过去了，该企业现在又回归老本行了，不再涉及防疫项目，但是人才都没了，招聘也因网上的各种爆料导致新员工不敢去入职，企业还有未来吗？

素材说明：

本文所述案例，绝大部分来自于本人的亲身经历，部分来源于该企业的知乎话题内各离职员工的爆料，少量来源于离职群和维权2群。因素材较多，本文并未将所有事情全部写入，被选用的案例基本都是我可以100%确认真实性的案例，那种无法证明真伪的一概未选用。虽然有些事根据同事的描述我能断定真实的可能性在99.9999999%以上，但对于未在这家企业工作过的路人来说，所述内容看起来未免会显得很夸张，甚至怀疑其真假。的确，对于未经历过的人来说，的确难以想象人可以坏到那种程度，企业可以无耻到那种程度，这已经不是网上那种常见的裁员纠纷导致仲裁的那种普通层级了，真实情况远远超出你的想象，甚至可以一再突破你作为人类的认知下限。所以这种案例我基本没选用，只写了一些大家尚能接受的案例。本文的首发日期是20240313，未来的几年内会不断更新，每当我得到新的素材并可以确认真实性，我都会将其更新至本文中。也欢迎各前同事踊跃提供各种案例，可以微信直接发给我，若不想告诉我你的身份，也可以用本平台站内私信的方式发。

更新日志（Release Notes）：

2024-03-13：初稿首发。