这是一个创建于 381 天前的主题，其中的信息可能已经有所发展或是发生改变。
https://mp.weixin.qq.com/s/WFLLU8R4bmiqv6OGa-QMcw
他们的公告的链接
考虑到 v 友的水平，我抛砖引玉分析一下
这帖子的意思大概是说，由于临时工在升级维护工具的时候，工具没有严格测试，直接上生产环境，工具的 bug 导致数据库服务器下线，联系硬件团队，硬件团队说上不了线，摆烂不玩了，你们自己恢复备份吧，然后花了四个小时恢复，俩小时验证数据，成功上线
我和几个朋友讨论了下，觉得非常的，不可思议
这是 2023 年的，语雀这个体量的公司，做出来的事情
正常的架构思维里，所有的服务，就不应该跑在同一台机器上，包括数据库，最次也该是个主从集群，集群下面的机器单例再考虑 raid 之类的东西
在这个设计下，不存在上不了线开不了机这种事情，机房被修卡军团占领了都没事
至于网上传的什么之前的技术负责人跑路了，新人不会操作
就正常的 devops ，后台管理面板里，全自动维护，包括版本控制，回滚，备份，集群，镜像，机器冗余，全部自动化管理
这不该是现在的标配吗
技术负责人跑路，新人不会操作，这句话假定的前提是，这一切都是手工完成的
语雀这么大公司，表现得跟路边三五个人创业的草台班子一样
他们的公告的链接
考虑到 v 友的水平，我抛砖引玉分析一下
这帖子的意思大概是说，由于临时工在升级维护工具的时候，工具没有严格测试，直接上生产环境，工具的 bug 导致数据库服务器下线，联系硬件团队，硬件团队说上不了线，摆烂不玩了，你们自己恢复备份吧，然后花了四个小时恢复，俩小时验证数据，成功上线
我和几个朋友讨论了下，觉得非常的，不可思议
这是 2023 年的，语雀这个体量的公司，做出来的事情
正常的架构思维里，所有的服务，就不应该跑在同一台机器上，包括数据库，最次也该是个主从集群，集群下面的机器单例再考虑 raid 之类的东西
在这个设计下，不存在上不了线开不了机这种事情，机房被修卡军团占领了都没事
至于网上传的什么之前的技术负责人跑路了，新人不会操作
就正常的 devops ，后台管理面板里，全自动维护，包括版本控制，回滚，备份，集群，镜像，机器冗余，全部自动化管理
这不该是现在的标配吗
技术负责人跑路，新人不会操作，这句话假定的前提是，这一切都是手工完成的
语雀这么大公司，表现得跟路边三五个人创业的草台班子一样
 |
1
cherbim 2023-10-25 11:28:12 +08:00
10 月 23 日下午，服务语雀的数据存储运维团队在进行升级操作
这么大的公司竟然选择下午升级，语雀正常用户大部分都是程序员吧，这些人一般上午开开早会，然后下午干活，正好用户使用高峰期，这个升级时间选择，就 tm 的离谱， |
 |
2
s7964926 2023-10-25 11:28:43 +08:00  17
别侮辱路边三五个人创业的草台班子，他们做的会更好。
|
 |
3
minami 2023-10-25 11:28:44 +08:00 146
人类组织的本质都是草台班子，那些看起来不草台的无非是里面有一小部分很牛逼的人顶着没出问题
|
 |
4
yyzh 2023-10-25 11:29:08 +08:00 via Android 7
很正常啊,支付宝当年不也一铲子下去之后就全国都挂了.所以那些扯什么异地双活啊异地灾备啊听听就算了.
|
 |
5
porjac233 2023-10-25 11:29:39 +08:00 1
阿里现在真是太拉了，每年都能出个 P0 的大故障，阿里云香港机房 C 区全面故障还记得吧。
|
 |
6
xingdaorong 2023-10-25 11:31:35 +08:00
听说外包团队已经开了，不知道真假
|
 |
7
yhxx 2023-10-25 11:33:57 +08:00 7
盲猜是很久之前上线的服务用了阿里云的旧型号的 ECS ，不小心删掉了，就没办法再买一个原样的出来了
然后一堆服务在新型号的机器上不兼容，只能手工处理 |
 |
8
nekoharuya OP @cherbim 正常更新时间应该是周四，这是阿里标配，我在 b 站看极海 Channel 说的，所以这个是典型的，没有走版本控制，代码审计，连自动化测试都没有，“临时工“闭着眼睛直接上生产环境的案例
|
 |
9
4kingRAS 2023-10-25 11:35:50 +08:00 7
很明显，是裁员了，新接手的大学生不熟练
|
 |
10
lqy2575395 2023-10-25 11:37:42 +08:00
现在阿里系的服务吹什么高可用，都可以打个大大的问号了
|
 |
11
tabris17 2023-10-25 11:38:09 +08:00
所以，所谓的下线是指把云服务器的实例给删除了嘛？
|
|
12
nekoharuya OP @yhxx 你这个分析太离谱了，首先，跑在容器里的服务，绕过阿里云的账户权限管理，把容器给删了，这个事情是做不到的，那就只能是拥有后台权限的人自己操作，删库跑路了
|
 |
13
Conantv2 2023-10-25 11:38:58 +08:00 3
带头人走了，团队变得松散，重要但万年不用一次的关键环节被忽视，不奇怪。当初把大部分人员抽走搞钉钉文档，结果钉钉文档没搞起来，语雀重新扩充团队却越搞越好，其实从这点就可以看出项目带头人的重要性。
以阿里的尿性，不能自负盈亏的项目都搞不长久，不久的将来，阿里旗下几大文档必定砍掉部分，不知道会不会是语雀。 |
 |
14
pengtikui 2023-10-25 11:40:04 +08:00 72
> 14:15 联系硬件团队尝试将下线机器重新上线； 15:00 确认因存储系统使用的机器类别较老，无法直接操作上线，立即调整恢复方案为从备份系统中恢复存储数据。
被你说成 > 联系硬件团队，硬件团队说上不了线，摆烂不玩了，你们自己恢复备份吧 造谣真简单啊 |
 |
15
Mess1ah 2023-10-25 11:40:05 +08:00 4
你的思考里面，从 跑在同一台机器上 这里开始就已经是全错了
|
 |
16
Aliencn 2023-10-25 11:42:19 +08:00 8
看起来是存储的集群太老了，有一些隐患没人敢优化，毕竟这种优化可能会造成无功有过。于是击鼓传花，直到一个倒霉蛋引爆了它。
不过我疑问的是，使用冷备恢复的数据，公告里还说所有数据都没丢失是怎么做到的。备份之后到问题发生之前的那些数据呢？ |
 |
18
ersic 2023-10-25 11:45:24 +08:00
openai 不也照样经常 down ，有时也几个小时
|
 |
19
theChampion 2023-10-25 11:46:31 +08:00 22
质疑草台班子 理解草台班子 成为草台班子
|
 |
20
aeli 2023-10-25 11:47:24 +08:00 3
运维工具，是不是引入了 terraform 之类的自动化定义，然后把资源给删除了？
|
|
21
nekoharuya OP 2
@pengtikui 机器太老了，上不了线，这个事情本身就是有点不可思议的，你看前几楼的回复，他们都认为是跑在阿里的 ECS 上，而不是自建机房才能通过删除 ECS 实例达成上不了线这个结果，但是看他们公告，他们的说法明显是自建机房，可能我技术很菜吧，我理解不了他这句话是怎么做到的，机器都在自己手里，是下线了又不是删库了，那我只能理解成摆烂不玩了
|
 |
22
BUHeF254Lpd1MH06 2023-10-25 11:50:21 +08:00
反正也越来越不好用了，早就不用很久了
|
 |
23
jjx 2023-10-25 11:50:48 +08:00
这个从备份中恢复我也很好奇
从备份恢复没有丢失数据, 怎么做到的 类似快照之类的应该都有个备份点, 不太可能不丢失数据 除非还依赖实时备份的数据库日志, 从日志中恢复增量部分 |
 |
24
sujin190 2023-10-25 11:51:19 +08:00 via Android
@isbase 以前那是支付宝内部 P0 故障，现在支付宝微信这种体量的再出这种直接工信部 P0 故障，你掂量掂量🤪
|
 |
25
luoway 2023-10-25 11:51:39 +08:00 2
7 小时完成离线新建存储系统，至少是公司内的最快记录了吧
|
 |
26
zackzergzeng 2023-10-25 11:52:08 +08:00
？假面骑士 1 号
|
|
27
nekoharuya OP @Mess1ah 别光喷呀，有何高见
|
 |
28
JensenQian 2023-10-25 11:55:03 +08:00
和最近 cs2 更新一样
各种奇奇怪怪的 bug 满天飞 修好这个又起来那个 |
 |
29
han1988 2023-10-25 11:55:28 +08:00
直接原因是外包或者新手写了有问题的运维工具。和当年携程一模一样。
反正运维在 IT 生态连最底端，根上就没治。 |
 |
30
pkoukk 2023-10-25 11:57:56 +08:00 6
存储节点怎么会跑在容器里呢？这种服务的存储大概率是用物理机来扛的，虚拟机性能撑不住。所以才有联系硬件团队下线重新上线的流程。
硬件团队不敢动，大概率是这机器用了很久了，和现有大环境的机型都不一样，当初为了做网络储存打通下了很多非标配置，可能没有持久化。这种史前机器，后续接手的人根本没办法短时间恢复，所以建议直接从备份恢复到新机器上一劳永逸。 |
 |
31
buchikoma 2023-10-25 11:59:32 +08:00 5
来猜下这个过程是什么样的
估计是运维工具 bug 导致华东 region 的一批机器下线，这批机型要么很老那么已经过保还未更换，关机再启动很多服务拉不起来，数据库又没有跨 region 部署，只能重新把本地盘或者云盘挂载到能用的机型或者 ecs 上做数据恢复，要是这样的话，耗时确实会很久 |
 |
32
sn0wdr1am 2023-10-25 12:00:22 +08:00
甩锅外包
|
|
33
nekoharuya OP @pkoukk 是容器还是直接在物理机上，在这个问题上，我认为是无关紧要的，而且这种体量，正常的思维必然是上集群来扩容，不管是加物理机器还是加容器都一样，数据库分布式的存储在不同的机器上，查询的时候也有很多便利的算法可以用，再给每个节点上个从属服务器，自动同步，在这个设计下，机器是新的是旧的，几台机器炸了，或者一两个机房被修卡军团占领了，都无关紧要的
|
 |
34
deorth 2023-10-25 12:10:51 +08:00 via Android
所有的团队都是草台班子
|
 |
35
pengtdyd 2023-10-25 12:14:14 +08:00
公告就是安抚用户的，你还真信里面的内容啊，太天真了吧。
|
|
36
nekoharuya OP @pengtdyd 别光喷呀，有何高见
|
 |
37
mazyi 2023-10-25 12:28:06 +08:00
其实我还是没有很搞懂，为啥运维工具可以直接下线服务器，理论上下线生产服务器这种操作，需要二次的吧
|
 |
38
qwerasdf123 2023-10-25 12:31:33 +08:00
@minami 卧槽 表达真到位！
|
|
39
nekoharuya OP 1
@mazyi 一种我目测最合理的可能，运维工具把那台机器的环境搞炸了，机器又是祖传的，根本恢复不动，服务跑不起来，所以上不了线，备份也不是真的备份，就是原始数据，他们新搭了个机器，在全新的，干净的环境里，起了服务，导入了数据
|
 |
40
weiwenhao 2023-10-25 12:38:14 +08:00 45
故障恢复文档放在语雀了，死锁了。
|
 |
42
julyclyde 2023-10-25 12:40:29 +08:00
另外，对于寄希望于“点点面板就可以”，我只能说这种大众认知其实正是事故隐患的来源
|
 |
43
fatekey 2023-10-25 12:45:07 +08:00
有效信息太少，没法评价
|
|
44
julyclyde 2023-10-25 12:46:32 +08:00
@mazyi 具体情况不知道。不过你问的这种情况确实有可能发生：
比如语雀作为赖着不走的用户占用一个虚拟机，这个虚拟机的宿主是一个旧硬件，已经被阿里云列入淘汰计划 这次语雀用户升级时，在没注意到里面有些“本地存储数据”的情况下，释放了这个虚拟机，然后其宿主机直接被自动化踢出，甚至格式化了 这种情况，即使之前做过演练也不一定能发现，因为演练的时候不一定会伴随发生 IaaS 层的变化，虚拟机里的本地存储数据在演练时也不一定重要到能看出事故的程度 |
|
45
nekoharuya OP @julyclyde 这其实是我的经验之谈，你不信任精心设计和经过反复测试和验证的自动化处理，却相信凭经验和感觉的人工手动操作吗
|
 |
46
nothingistrue 2023-10-25 12:54:02 +08:00
文档服务，你搞数据库主从集群，你这路子更野。
|
|
47
julyclyde 2023-10-25 12:54:10 +08:00
@nekoharuya 你这样说其实是假设面板都经过反复测试验证了
这种事能随便假设么 |
|
48
nekoharuya OP @nothingistrue 别光喷呀，有何高见
|
 |
49
zachary99 2023-10-25 12:57:59 +08:00 via Android
应该是当初设计架构的可能都走了，这块从来没做过，没交接下来
|
|
50
nekoharuya OP @julyclyde 小公司自己手动操作确实居多，我以前的时候，也是从手动操作->自动脚本->gui 工具，这样积累起来，但是，语雀这么大个公司
|
|
51
julyclyde 2023-10-25 13:03:52 +08:00 1
|
 |
52
adoal 2023-10-25 13:08:01 +08:00 4
小团队小草台，大团队大草台，老系统老屎山，新系统新屎山
|
 |
53
wangshushu 2023-10-25 13:11:33 +08:00
语雀早就被钉钉团队合并了，其实原来内部是竞合关系，收编之后语雀的人走了很多
|
|
54
nekoharuya OP @julyclyde 我们其实是基于两种假设
我的假设是，人工操作不可靠，是人就一定会出问题，信任人的技能熟练程度不如信任工具的完善程度，因为工具的更新是一证永证的 你的假设是，问题持续在变化，能用工具覆盖的问题本身就不应该出现，所有出现的问题都是未知的，只能依赖工程师抢救 我觉得你的想法挺有道理的，就不争论这个了 回到问题本身，我认为语雀这个故障和处理方法，不管是哪种假设，它都不应该出现，因为完善的架构方案和工具链实在很多 |
|
55
julyclyde 2023-10-25 13:27:34 +08:00 1
@nekoharuya 首先，工具的更新并不是一证永证的
因为现实中的工具只是人的眼神，人有多大权限，工具最多也就有多大权限 语雀肯定管不了阿里云啊 假设我前面 44 层的猜测正确，那么阿里云提供抽象的服务，没有任何过错； 语雀的程序实际有本地状态却按无状态来处理，没有揭示风险给工具开发者，导致工具和被运维的目标不配套，但二者都是他们自己开发的，他们自己应该负全责。在这种情况下假设工具正确没有什么意义 甚至可能出现，刚开始二者是配套的，后来服务程序被谁改成了有本地状态，而工具依然按无状态来做，导致故障。这就是典型的违反你的一证永证假设的情况 |
 |
56
dayeye2006199 2023-10-25 13:37:59 +08:00
多大的事儿，谷歌都全网挂过，各种分布式容灾，但还是挂了
|
 |
57
binaryify 2023-10-25 13:42:50 +08:00
玉伯都去字节了
|
|
58
nekoharuya OP @julyclyde 你 44 层的分析我认真看过了，这其实还是我最开始说的架构设计的问题，机器是物理机还是虚拟机，横竖都只是个容器，上层上个集群，下面的容器怎么更新都没关系，把机房拆了都行，语雀这种单例设计是我主要喷的点
然后你说的人的眼神，还有设计上无状态有状态的变化，这是不是很符合我说的，完全无法避免是个人一定会出错 既然不能避免，就更应该自动化，去依赖化 至于工具的一证永证当然指的是相同条件下，外部条件变了自然要重新开发，也就是我认同你说的依赖工程师解决全新的问题 |
 |
59
dolphintwo 2023-10-25 13:47:08 +08:00 2
抱歉，我个人觉得这个流程似乎没什么问题，时间上重建存储服务+日志恢复+完整性校验，作为只有单点冗余的结构
7 个小时应该是正常的。后面也说了会换两地三中心，除了删库这个时间点，暂时没看出有什么可喷的。 大家都是草台班子，谁也别笑谁。 |
|
60
julyclyde 2023-10-25 13:49:06 +08:00
|
 |
61
m0612 2023-10-25 13:53:21 +08:00
再大体量的平台，后面可能就几台单机跑着
|
 |
62
xingjue 2023-10-25 13:53:23 +08:00
裁员了
|
 |
63
dode 2023-10-25 13:57:48 +08:00
透露处理的细节内容太少了，
|
|
64
nekoharuya OP @dolphintwo 重建存储服务+日志恢复+完整性校验，这个流程，在故障已经发生时，是没有问题的
我主要分析的是，他的故障以及故障处理流程透露出来的背后的架构方案，开发和运维模式 上面已经讨论过很多楼，感兴趣可以自己康康 |
 |
65
dreamusername 2023-10-25 14:03:52 +08:00 1
@aeli #20 内容没讲，只说运维工具有 bug ，一般来说操作资源的也就是 terraform 或者 pulumi 之类的声明式管理工具
|
 |
66
shakoon 2023-10-25 14:04:17 +08:00
@cherbim #1 下午做版本更新确实离谱，从这一点就可以看出这是个管理及其混乱的公司，以至于后面那些相互甩锅的行为就没那么不自然了
|
|
67
nekoharuya OP @julyclyde 这个不是努力目标啊……当然映射到个人可能是一种思想，但是在 2023 年，已经有很多成熟的框架和方案了，比如我说的分布式集群，结果他们就自己意识流开发，这是我说他野路子的根本原因啊……
|
|
69
nekoharuya OP @julyclyde 顺带一提这里参考的体系是微软
|
 |
70
aaronkk 2023-10-25 14:11:27 +08:00
别的不说，可以白嫖六个月的会员了
|
 |
71
lambdaq 2023-10-25 14:12:14 +08:00 1
只有我一个人觉得上午、下午版本更新挺好的么？
上班时间干事，越早越好 谁愿意加班发版？晚高峰发版？ |
|
72
pkoukk 2023-10-25 14:14:52 +08:00
@nekoharuya #33 这是理论上，但现实里，预算不是无限的，机器的性能也不是无限的。更何况，公告里提到了，是某个 region 的节点故障，可没说只有一个节点故障，一个 raid5 挂两个不是一样凉凉？
|
|
73
nekoharuya OP @aper 周一下午更新确实是个奇怪的时间点，先参考敏捷体系，两周一个冲刺，冲刺完就更新，以周为单位，更新时间点当然不会是在周一，那 IPD 体系呢，IPD 体系纯瀑布流开发，所有设计在事先都规划好，所有的技术细节都通过假设和验证了，再进入开发，开发完了以后还有繁琐的测试，参考华为和甲骨文，所以 IPD 的概率也不大，不是主流体系，那就是意识流了，意识流开发，然后选择在周一下午这样的用户在线峰值时间段，做没有严格测试过的更新，所以是草台班子
|
 |
74
zsdroid 2023-10-25 14:17:16 +08:00 7
@nekoharuya #21 你觉得不可思议就说不可思议啊，直接造谣算几个意思。
|
 |
75
SixGodHave7 2023-10-25 14:17:45 +08:00
世界就是个草台班子，一群裱糊匠对付对付完事儿
|
|
76
nekoharuya OP @aper 不过这个问题不是那么重要，大家谁还不是个意识流了
|
 |
77
pinkbook 2023-10-25 14:18:53 +08:00
就算数据库全坏了，也不至于网页都打不开，顶多有些操作报错而已。官网和存储用户笔记 是两回事吧。
正常来说，官网只是个前端页面。这个通告很假 |
 |
78
encro 2023-10-25 14:21:04 +08:00 1
随时随地可更新的才是正规军，
你以为语雀开发很多？ 我认为开发加测试加产品 10 个有点多了。 |
|
79
nekoharuya OP @lambdaq 下午不下午不要紧，主要是周一，要么周末出去玩回来，忘了自己写啥了的情况下更新，要么早上摸摸鱼，下午直接更新，当然这是开玩笑，一般避开用户峰值，大多会选择周四什么的，不过这个不是很重要
|
|
80
nekoharuya OP @pkoukk 加机器数量的成本肯定是比怼单台机器性能低的，这也是分布式能够存在的根本原因，然后，可能我用词不够准确，一套 raid ，不管是 015610 ，都是算作“单例”的，因为都不是独立的多个环境
|
 |
81
Rrrrrr 2023-10-25 14:37:03 +08:00 2
难道用户就没错吗？ 😊
|
|
82
nekoharuya OP 2
|
 |
83
NCZkevin 2023-10-25 14:48:49 +08:00
再严格的工具也也挡不住人的操作，前两年在和阿里差不多同级别的公司，碰到不小心把 K8S 集群（千台机器规模）的所有 master 给批量下线的误操作，喊来一堆大佬，搞了一晚上才恢复。啥容灾主从多 region 碰到这种都不好使。
|
 |
84
MRG0 2023-10-25 14:49:07 +08:00
b 站是不是也挂一次，b 站出的说明就比较详细
|
|
85
nekoharuya OP @NCZkevin 我想起之前公司，游戏内测第二天，老板打开谷歌云后台，自己瞎操作，把服务器删了……
|
|
86
nekoharuya OP @NCZkevin 后来公司寄了，这大哥现在在 supercell 上班，希望他别把人服务器也删了
|
 |
88
aper 2023-10-25 14:59:52 +08:00
@nekoharuya 你开发发布还遵从啥敏捷体系？这玩意我自从大学书上学过后面就再没碰过了，你真是写代码的吗？
|
 |
89
NoOneNoBody 2023-10-25 15:03:16 +08:00 1
看样子 OP 仍然信任语雀
我觉得此文不是七小时后写的，而是写了七小时 |
|
90
lambdaq 2023-10-25 15:04:25 +08:00
|
 |
91
liq65451 2023-10-25 15:04:41 +08:00
“服务语雀的数据存储运维团队”，所以这数据库运维不是语雀的人，是蚂蚁金服干的？
|
|
92
nekoharuya OP @aper 碰啊，你翻翻我发的第一个帖子，如果能看懂，咱俩加个 v 聊聊 ai 撒，体系这种东西，你不碰，大概率就是别人代偿了，比如游戏公司一般是策划代偿了，我之前一路混到了独角兽公司的架构师岗位，现在在小创业公司做 CTO ，我管理水平也就半桶水，就之前被逼着学一点，主要还是靠写代码的硬实力
|
 |
94
hancai 2023-10-25 15:11:25 +08:00 6
"就正常的 devops ，后台管理面板里，全自动维护，包括版本控制，回滚，备份，集群，镜像，机器冗余，全部自动化管理
这不该是现在的标配吗" 把我干沉默了， 哪来的标配。能做好这一套的基本都是大厂，但语雀这体量算是大厂了。 |
|
95
nekoharuya OP @lambdaq 语雀上线也不是一天两天了，大家上班也不是每天 24 小时都用什么钉钉飞书，他们后台肯定是有在线数据分析的，我觉得大概是更新的人觉得改动很小，不重视，没当回事，而且又是和用户没有直接关系的运维工具，从我的经验看，包括我自己，大部分人都会有这种蜜汁，然后闹出事故的经历的……不过这就是我瞎猜的了
|
 |
96
VB1 2023-10-25 15:12:28 +08:00
@nekoharuya 你在 21 楼分析的跟我想的差不多，你的帖子里面说“正常的架构思维里，所有的服务，就不应该跑在同一台机器上”。我猜测他们可能不是跑在同一台机器上，而是所有的机器都是祖传的，一升级全升级，然后集群炸了，反正我是不相信他们一台机器上存储这整个华东地区的数据
另外就是他们自己也说了是存储服务器，我的工作经历比较少，但是我觉得大部分公司的存储服务器应该不会跑在容器里吧，所以从这一点上，你说的“就正常的 devops ....”是不成立的，存储服务器炸了只能通过“硬件团队尝试将下线机器重新上线”这种方式 以上观点的都是建立在他们的公告为真的情况下分析 |
 |
97
CoderLife 2023-10-25 15:16:39 +08:00
看来大多数人都是付费用户
|
 |
98
bydmm 2023-10-25 15:18:39 +08:00
谁能告诉我为什么语雀不用阿里云的 RDS
|
|
99
lambdaq 2023-10-25 15:19:59 +08:00
|
|
100
nekoharuya OP @VB1 容器这里是我用词不准确，这里的语境是，不管是虚拟机还是物理机都是容纳数据的容器
当然，产生歧义是我不对 然后，从真实场景上看，你看上面的回复，大多数人认为，他们就是上了套 raid ，具体哪套 raid 不清楚，不过不重要，没有更多的信息，但是应该大差不差 我的观点是，这种不是独立环境的，可以称为一套/一台/一个机器 |
Select Language