1
ztm0929 64 天前 via iPhone 4
主要是因为人员变动,裁员裁到动脉了
|
2
evan9527 64 天前
降本增笑
|
3
fffq 64 天前 2
怎么实现我不管,明天上线
|
4
jasonkayzk 64 天前
降本增笑不是说着玩的。
|
5
weian 64 天前
肯定是裁员呗
|
6
lithiumii 64 天前 via Android
以前互联网公司也没这么重要,随便谁崩几个小时不够上新闻
|
7
virusdefender 64 天前
即使是大公司稳定性也是大量的资金和人员保障出来的,比如主备机房网络和服务器、运维 24 小时值班等等,这部分支出减少了之后,经常崩我觉得也可以理解。
|
8
mywind 64 天前
关注度和影响力的原因,小公司软件天天崩,用户都没几个,自然没什么人关注
|
9
lujiaxing 64 天前 6
一方面是的。任何系统都是这样,越复杂,出问题的概率越大。目前已知的唯一一个极其复杂但没有任何 BUG 的系统就是物理。但这是神的领域,非吾等凡人可以企及。对于人类来说,人的大脑终归是有极限的,能想到的逻辑分支也是有限的。制造出来的系统必然也会有 BUG 。此事古难全。那么为了完善这种复杂系统,就需要很多的人一起来维护。但是现在中国大陆经济政策严重失误 + 全球经济下行的大环境下,各企业都为了自保开始裁员。这就导致一部分复杂的系统缺少必要的维护,进而产生崩溃等问题。
|
10
niubee1 64 天前 1
基本的概率学,当一个服务可靠度 99.9%,100 个服务组合成的系统的整体可靠度就只有 90.4%了,其实微服务在遇到裁员砍到大动脉后,系统可靠度会指数级别下降
|
11
crackidz 64 天前
因为互联网公司都在降本增笑
|
12
sagaxu 64 天前 1
以前事儿也不少,
2005 年的金手指事件,“以 61 万日元的价格,卖出 1 股”,误操作成“以每股 1 日元的价格,卖出 61 万股”,由于交易系统的 bug 无法撤单,瑞穗证券损失超过 400 亿日元。 2012 年雅虎日本,系统故障导致 5000 多家客户丢数据。 2015 年还是雅虎日本,丢失 200 多万个邮件。 2020 年还是雅虎日本,错改几十万账号地址,导致发货发错人。 |
13
des 64 天前 17
你以为的:裁到大动脉了,大崩溃
实际上的:裁到屁股了,兜不住屎了 |
14
Tink 64 天前
以前也崩,但是大家不知道
|
15
Falcon1 64 天前
换代速度太快了,要是一个版本不动用十年,基本 bug 都排除得差不多了
|
17
jim9606 64 天前 via Android
增长期:死堆人力撑着,不然影响用户信心就拉不到投资了
平稳期:炸就炸吧反正低价值用户 总有人拿推特裁员说精准,我就没觉得现在推的搜索和突然上传可靠过 |
18
lneoi 64 天前 1
换个角度考虑,接受几次崩溃之后人员能够熟悉问题稳定维护,换来能够削减人员,说不定就有想冒这样风险的,实在搞不定的再把几个大牛招回去,其他的依然削减。
|
19
mytsing520 64 天前
本质上是资源占用的矛盾
|
20
James369 64 天前
不注重测试和维护,只会加功能
|
22
YVAN7123 64 天前
降本,没有主备系统了呗
|
23
Foxkeh 64 天前
感觉像游戏一样停机维护还更直接更靠谱一些
|
24
dif 64 天前
一方面:系统大了就会这样,我以前参与的项目十几个人一起开发,经常有雷。
另一方面:我经历过的都是快速迭代,有坑再填。实际上老板要求填坑也不能影响迭代,所以,慢工出细活还是有些道理的。 |
26
Perry 64 天前 via iPhone
听离职推特的朋友说的,推特裁员把很多高水平的逼到主动辞职(离职包裹给的还行),留下来的都是等绿卡的外籍程序员(印度为主)
|
28
512357301 64 天前 via Android
本质上还是用户量太大了,用户量涨一个数量级,硬件成本不能也涨一个数量级啊,而且机器多了,运维成本也高了。
功能多,用的人多了,代码量自然也就大了,为了快速迭代,提升开发速度,自然架构就复杂了,专人专岗是效率最高的方式。 说到底所谓的互联网大厂,本质上就是一个个开发工厂。特别是那些外包公司,更是血汗工厂。 |
29
james122333 64 天前
所以简单的东西才是王道 刻意复杂化的东西没有不垃圾的 不论使用还是学习
现在流行的大多是垃圾东西 |
30
guanhui07 64 天前 via Android
降本增笑
|
31
james122333 64 天前 via Android
如何简单精妙实现一样的效果才是吾辈追求
|
32
smlcgx 64 天前 via iPhone
人类总是乐观看待风险和高估自身能力
能抵抗百年不遇的洪水 闯一个红灯没关系的 把老员工都裁了不会有问题的,系统很成熟了 |
33
scienhub 64 天前 2
@lujiaxing "目前已知的唯一一个极其复杂但没有任何 BUG 的系统就是物理": 很有意思的点。
但是物理系统之所以没有 bug ,可能是因为我们意识里就觉得物理世界是对的,如果没有按我们理解的运行,那肯定是我们理解有问题。比如光地双缝干涉这种,你可以认为这是物理世界的 bug ,但是绝大部分人,都认为这是物理世界的规则,只是我们没有理解透彻。 |
34
laminux29 64 天前 1
这并不是什么裁到大动脉,而是老板、项目经理不愿意付出时间成本,来给员工预留写文档与读文档的时间,导致员工踩坑。
团队协作的场景,为了确保软件质量,为了减少坑,每个员工,在做实现之前,必须要写详细的设计文档,交接工作时必须要读完前任写的文档。但只要你去打听,在国内,无论大小厂,无论体制内外,极少听说老板与项目经理,预留足够时间,让员工去读写文档。 不写文档,不读文档,自然会容易踩坑。 你问问你自己,你的上级,给你预留写文档与读文档的时间了吗? |
35
GoLand 64 天前
多方面原因因素:
1. 复杂度确实增加了,迭代时间越久,加上各种砍一刀、优惠券乱七八糟的功能,系统肯定变得更复杂了,相对应的稳定性必然会下降。 2. 使用的人多了,同样复杂度的系统,要做到可用性 99.99%,100QPS 和 1 万 QPS 难度差很多很多。 3. 迭代变快了,以前竞争没这么激烈,需求迭代也比较慢,变更引入的事故也少。 .... |
36
iovekkk 64 天前
我司之前裁了一个外包都裁了出问题了你敢信不?
原因就是这个外包不知是有意还是无意反正非常注重防御性编程,代码一坨屎但是能勉强运行 他在职的时候就属他的模块 bug 最多但是他愿意加班维护,不会太拖延整体进度 他离职之后其他人都不想接手他的代码,迫于无奈,领导从其他项目里要了一个人过来 结果新来的人搞了快两周还没熟悉他的代码,bug 改不过来新需求完全做不了 于是现在又把他重新招回来了,降本增效又一经典案例 |
37
p1gd0g 63 天前
以前也不少吧?可能以前信息流不那么顺畅,出事未免会成为热点
|
38
satoru 63 天前
组织架构也变臃肿了
|
40
opengps 63 天前
你既然要说以前,可得知道那时候都是停机更新。各种功能融合在一起,甚至一个错别字都得中断几秒钟
|
41
ala2008 62 天前
所以互联网所谓的可用性 11 个 9 都是假的( doge
|