这是一个创建于 1630 天前的主题，其中的信息可能已经有所发展或是发生改变。
我司我组的运维都看着挺辛苦的，经常半夜两三点起来处理故障问题，因为经常有致命告警。他们往往对某些实现上的细节不清楚，所以也很有可能把主导项目的开发 leader 叫起来，于是大家都在深更半夜不太清醒的状态下处理故障。
我一直在想，如果开发把功能做得完备些，特别是在上线前多测试演练，多在可能故障的地方埋点以帮助在意外情况下可以恢复到 一个慢但准确的 Plan B 的执行路径上来，这样哪怕半夜被叫醒，也可以快速迁到 plan B，不至于人为操作半天，毕竟人不在清醒情况下更容易出问题。
所以我总觉得运维如此辛苦，是开发
1 ）没有用心把系统做得故障冗余
2 ）没有重视上线前测试演练
3 ）没有配合和敦促运维一起做好面板监控和自动化处理（于是乎总要通过慢的命令行的人工操作）
的结果。（我自己是开发 ，所以也会审视我们的开发队伍）。大家觉得呢
我一直在想，如果开发把功能做得完备些，特别是在上线前多测试演练，多在可能故障的地方埋点以帮助在意外情况下可以恢复到 一个慢但准确的 Plan B 的执行路径上来，这样哪怕半夜被叫醒，也可以快速迁到 plan B，不至于人为操作半天，毕竟人不在清醒情况下更容易出问题。
所以我总觉得运维如此辛苦，是开发
1 ）没有用心把系统做得故障冗余
2 ）没有重视上线前测试演练
3 ）没有配合和敦促运维一起做好面板监控和自动化处理（于是乎总要通过慢的命令行的人工操作）
的结果。（我自己是开发 ，所以也会审视我们的开发队伍）。大家觉得呢
 |
1
pushback 2020-06-09 10:20:53 +08:00  26
你真是开发？
|
 |
2
baiwfg2 OP 当然，开发这边确实有可能因为人力不足，deadline 期限等原因，将就上线，这不是开发 的问题，管理问题
|
 |
3
mhycy 2020-06-09 10:22:53 +08:00
如果投入的钱足够多，平台足够稳定可靠，那么被叫起来的就是开发了
|
 |
4
zhilincom 2020-06-09 10:23:25 +08:00
告警不是应该直接电话打到对应开发的手机上吗？要区分是什么告警，对应的负责人都分配好。
|
 |
5
HansLee 2020-06-09 10:24:32 +08:00 2
当然学学我亚麻巨硬谁开发谁 oncall 啊，开发被叫起来的多了就会去思考业务之余，怎么提高系统稳定性了
|
 |
6
rrfeng 2020-06-09 10:26:06 +08:00 via Android
SRE 了解一下
|
 |
7
index90 2020-06-09 10:26:10 +08:00
我比较好奇为什么致命告警总是半夜两三点爆发，而早上的却很少听说？
半夜两三点流量特别大？早上却很小？ |
 |
8
ly4572615 2020-06-09 10:27:14 +08:00 1
有很多手段可以不用接电话，但是一个不小心就是成本翻倍
|
 |
9
Ariver 2020-06-09 10:29:43 +08:00
devops.
|
|
10
baiwfg2 OP |
 |
11
murmur 2020-06-09 10:35:49 +08:00
运维有值夜班的，这是他们的工作，不用开发操心
|
 |
14
anjing01 2020-06-09 10:47:11 +08:00 2
三更半夜运维接告警有几种：
1 、硬件告警，如内存错误 /Raid 降级类，这种基本上通过冗余等方式解决 2 、外企，服务对象是国外客户有时差，这个以前是叫应用运维，现在是叫 SRE/DEVOPS 解决，项目详细的抛错代码及对应解决方案 wiki，监控是全流程的埋点，可以很快定位是哪里有压力或者瓶颈。至于打印堆栈 /dump 内存这种看贵司花多少钱招运维把，5000 的运维肯定是干不了的； 3 、晚上定时任务类的，大数据处理类的，这种基本放到凌晨跑，出了故障也比较常见，基本上运维可以解决。 |
 |
15
barrysn 2020-06-09 10:50:46 +08:00
@index90 问题很多，业务变更可能是开发问题， 也可能是运维问题，也可能是流程问题，也有可能是资金问题等等
并不能确定是哪里的问题， 其实楼主说经常性看到运维半夜处理紧急问题，这个应该说明 公司内部肯定是有问题的，但一直没有处理或者没有更好的处理办法， 业务变更是我猜的，还有可能是跨境业务 |
 |
16
U97F3 2020-06-09 10:51:31 +08:00 2
你们没测试？
|
 |
17
cmdOptionKana 2020-06-09 10:52:02 +08:00 4
这让我联想到餐厅清洁工的怨言。
以前我听到过餐厅清洁工埋怨客人把地方弄得太脏，导致她们工作很辛苦。 但是这里有个悖论：如果客人素质都非常高，不仅不会不小心把东西弄到地上，甚至多数人还会自觉收拾桌面，那么，结果就是餐厅会减少清洁工的数量。 比如宜家餐厅提倡客人自己收拾，他们就可以招聘更少的清洁工，降低成本。但这对清洁工来说是坏消息啊…… |
 |
18
heyjei 2020-06-09 10:54:11 +08:00 1
还有夜间批处理业务，数据必须在第二天上班前准备好的。
|
 |
19
heyhumor 2020-06-09 10:56:12 +08:00
辛苦钱辛苦钱，没有辛苦没有钱。别瞎操心了
|
 |
21
tabris17 2020-06-09 10:58:23 +08:00
你让运维无事可做他们才会恨你
|
 |
22
passerbytiny 2020-06-09 11:00:16 +08:00 via Android
从经常半夜两三点发生致命告警，到经常半夜两三点不太清醒的状态下处理故障，再到经常半夜两三点发生致命告警——胳膊要有胳膊的觉悟，你是扭不过大脑的。
这种情况，要么是领导层已经烂掉了，要么是领导层权衡过后认为现状就行。但不管哪种情况，作为小开发，该管的事是“提出问题”，而不是“怎么解决问题”。 |
 |
23
ww2000e 2020-06-09 11:02:33 +08:00
反了，开发是要确保告警稳定有效，能给运维喊醒。。
|
 |
24
coderluan 2020-06-09 11:45:21 +08:00
开发做的更好 -> 运维减轻负担 -> 部分运维被"优化" -> 给开发涨工资.
楼主老千层饼了(狗头). |
 |
25
fueen 2020-06-09 11:55:53 +08:00
你心疼运维，谁来心态开发呢？
|
 |
26
Jooooooooo 2020-06-09 12:50:04 +08:00 1
除去通常的评审, review, 测试等等环节, 上线变更一定做好:
1. 可灰度. 尽量可灰度, 能用线上小流量验证, 出现问题影响范围也可控. 慢慢扩量. 2. 可回滚. 尽量可快速回滚 (比如一键的配置开关), 一旦出现问题立马退回上线前一模一样的代码, 防止大面积故障长时间得不到处理. 3. 可监控. 尽量上线的内容是可以通过某种监控指标等确认是正常的. 一般是确认业务正常 (比如上报业务指标等), 如果会影响性能还需要确认系统正常 (比如监控上线前后的 cpu 等等) 严格做到这三点, 能规避不少问题. |
 |
27
firefox12 2020-06-09 13:00:38 +08:00
从设计上就要解决了， 应用出现故障 可以降级吗？ 可以加节点完成吗？ 有自助的解决方案吗？ 有完善的监控帮助观察吗？ 有足够多的业务监控 帮助定位问题吗？
设计师的水平就没达到，不靠人力靠什么？ 设计师的水平达到了，那么就砍人啊，需要那么多人干什么？ |
 |
28
Amance 2020-06-09 13:05:08 +08:00
减轻负担要运维干什么
|
 |
30
Songxwn 2020-06-09 13:54:39 +08:00
运维狗表示，有这么为运维着想的开发表示欣慰。
|
 |
31
yuanbo6 2020-06-09 14:04:28 +08:00 1
昨晚上十二点四十被电话叫醒救火的路过。
本人非开发，算是实施交付的小 leader，成天和我们的研发商务技术等等部门打交道。 目前不处理一线问题了，处理二线问题多一些。 我觉得项目碰上半夜救火这种事情很多方面的因素都有， 1.比如我程序极限承载能力是 10W 并发，集群承载能到 20W，但是客户拿去招投标就说 20W，结果实施方案计划并没有涉及集群部署这样，这是方案留下的隐患问题。当然也存在商业沟通的问题。 2.比如程序设定的功能 A 很好但是 A 不符合用户实际使用需求，用户提了个 A+的功能，然后单纯的为了那个+去做定制开发，为了定制而定制，定制开发这种事容易出问题我就不多说了……我们后面可能发现 A+确实更贴合实际需求，但是下一个版本乃至大版本更新都没有把 A+纳入基线开发，还只推出 A 功能，就还会重复做 A+开发，怕研发兄弟们工作量不饱和吗？……这算是产品规划方面的问题 3.在开发过程中吧，确实很多情况现场生产环境和开发环境不一样（成天听研发大兄弟和我诉苦），尤其是一个产品分了很多模块，每个模块又特别细化到单个小组为单位进行开发，可能真就是自己测试自己的那些功能性能啥问题都没有，然后一到现场，这个接口不对，那个字段不对……内部沟通也有些问题 4……一时间想不到了。不说了我去补觉了，三点多才睡。 世界上没有完美的程序，也没有完美的产品，也没有完美的人。产品、研发、交付、运维、商务……都不容易。 |
 |
33
airplayxcom 2020-06-09 14:10:57 +08:00
开发都把雷排完了 要运维干嘛？
|
|
34
airplayxcom 2020-06-09 14:12:11 +08:00
我司运维天天在那儿嗑瓜子闲聊呢
|
 |
35
beidounanxizi 2020-06-09 14:14:38 +08:00
这是老板对公司技术人才不重视的原因，
你们估计没有 devops 吧， 这种问题不应该是直接告警通知到部门负责人啊 还需要运维 夜里爬起来干活 🐶 |
 |
36
nnd 2020-06-09 14:56:53 +08:00 14
楼上一个个狗开发，能不能做个人啊？自己辣鸡菜，还美其名曰给运维找工作，不让运维别优化。 按你这样讲，需求每天变更一次的产品需求，每周重写一份 PRD，才是给你找工作，避免别优化的最好手段。 运维不用你找工作，我们有自己的工作，不了解请闭嘴。总是感觉自己比别人能力强，比别人聪明，这是病，赶紧治。
|
|
37
nnd 2020-06-09 14:59:59 +08:00
@nnd #36 如果一个运维只能天天嗑瓜子闲聊，这是对自己不负责，对公司不负责。不过运维天天嗑瓜子的闲聊的公司，也不是什么厉害的公司。这样的运维，这样的公司对社会对没有太大帮助，建议一起优化掉，提高社会效率
|
 |
38
tolerance 2020-06-09 15:00:10 +08:00 2
开发是应该尽可能列出可能出现的异常情况，并告知运维如何处理，让运维能够对应状况处理，而不是出现问题就把开发叫来现场分析问题。
|
 |
39
freelancher 2020-06-09 15:20:03 +08:00
想到我以前上班的游戏公司。基本上游戏运行中没自己挂掉过。偶尔一次二次，特别少。我们运维自己硬件和系统和应用层面都顾得好好的。工作起来那叫一个轻松。
可惜老板做死，把公司弄黄了。现在都找不到这么靠谱的开发团队了。 |
 |
40
pmispig 2020-06-09 15:23:27 +08:00
具体要看是什么问题吧，能不能举点例子
|
 |
41
wande6 2020-06-09 15:24:33 +08:00
变相体现存在价值？
|
 |
42
diggzhang 2020-06-09 15:30:51 +08:00
我们遇到的问题集中在夜间大数据批处理任务执行期间。
底层数据源交付听着简单，实则充满未知和坎坷。 有时候因为特殊硬件故障或底层服务故障 call 人家运维小哥就觉得十分抱歉。 在此吐槽广大数据开发真心是 007 陪跑。 |
|
43
airplayxcom 2020-06-09 15:47:54 +08:00
@nnd 运维就看看监控 不服咯？
|
|
44
airplayxcom 2020-06-09 15:49:45 +08:00 via iPhone
@nnd 要不，只留运维，把开发优化掉吧
|
 |
45
imn1 2020-06-09 15:56:18 +08:00
try
catch...pass 然后开发背锅，运维不用背锅 这种算不算？ |
|
46
airplayxcom 2020-06-09 15:57:55 +08:00 via iPhone
顺道进去看了下该运维的活动历史，就是知道有多闲，嘎嘎
|
 |
47
suotm 2020-06-09 15:58:33 +08:00
SDE on call
|
 |
48
dayeye2006199 2020-06-09 16:01:21 +08:00 via iPad
Oncall 了解下，管杀又管埋
|
 |
49
defunct9 2020-06-09 16:02:03 +08:00
开发的眼里是没有网络的，世界皆网线。
|
 |
50
Erroad 2020-06-09 16:04:44 +08:00
业务运维不是不尴不尬的，可以参考某些公司啊，全是系统运维，业务出问题研发自己先顶
|
 |
51
nieqibest 2020-06-09 16:09:52 +08:00 via Android
多招点运维
|
 |
52
tsaohai 2020-06-09 16:11:13 +08:00
把运维裁了，devops 一把抓 🐶头
|
 |
53
sardine 2020-06-09 16:43:23 +08:00
运维不搞自动化平台么
|
 |
54
workspace 2020-06-09 16:49:55 +08:00
回滚啊 代码有问题就是开发问题 直接回滚 然后找开发，代码没问题了重新上线
|
|
55
nnd 2020-06-09 16:57:41 +08:00
@airplayxcom #44
运维就看看监控 不服咯？ 你是不是只会 CRUD，牵来一只猴培训三个月也行； 要不，只留运维，把开发优化掉吧？ 要不把公司老板，前台，行政，测试，HR，保洁都优化掉，只留你一个开发； 顺道进去看了下该运维的活动历史，就是知道有多闲，嘎嘎。 别嘎了，赶紧跑吧，等下烤鸭店师傅马上就来了。我顺道进去看了下你的活动历史，你也不忙啊。 另外我前两年薪水年终奖不错， 现在休息去了，没上班。下次看历史记录的时候，多翻翻，我在一个主题里面回复过。 |
 |
56
Ksmriacle 2020-06-09 16:57:49 +08:00 1
感觉在 V2EX 运维就是🐶啊
|
|
57
airplayxcom 2020-06-09 17:22:10 +08:00
@nnd 哦 好的，大运维。谢谢提醒，我去写 bug 了。
|
|
58
pushback 2020-06-09 17:36:29 +08:00
@airplayxcom crud 能有什么 BUG，是个人都能写好吗🐶
|
 |
59
wobushizhangsan 2020-06-09 17:36:34 +08:00 via Android
我们这认真设计测试的功能最后都放弃或者变的不重要，那种紧急开发跳过测试紧急上线的功能不仅重要还高频使用。
|
|
60
airplayxcom 2020-06-09 17:44:11 +08:00 via iPhone
@pushback 哦 那你写不写呢
|
 |
61
1oNflow 2020-06-09 17:46:11 +08:00
有专门运维和 SDE 也管 oncall 的公司比例大概怎样？
|
 |
62
dolphintwo 2020-06-09 17:46:22 +08:00
我运维在这还不如🐶
|
 |
63
wangkun025 2020-06-09 17:49:24 +08:00
说服你老板晚上和节假日关机。
|
 |
64
ppphp 2020-06-09 17:59:35 +08:00
有 sre 就走 sre 流程，没有 sre 就看强势部门的，开发强势就开发来，运维强势就离谱，快逃吧
|
|
65
pushback 2020-06-09 18:28:27 +08:00
@airplayxcom 那种低级业务我才不写，给运维写去吧🐶
|
 |
66
Ansen 2020-06-09 19:03:09 +08:00 via iPhone
运维的日常： 一切正常，我们花钱请你来干啥？ 服务器异常，我们花钱请你来干啥？
运维路过！个人经验是大多数程序上的问题还是测试流程的问题，极少数情况是确实测不出来，这个没办法，全部操起来解决问题！ 至于非程序上的问题，除不可抗力因素之外，基本上都是运维本职工作没有做到位引起的，这锅得运维自己背！ |
 |
67
testsun 2020-06-09 22:11:47 +08:00
我觉得开发这么辛苦是因为运维保障不了基础设施的稳定运行。负责运维的领导开会说，一切运维异常情况都可能发生，但你们开发的代码必须考虑到所有运维发生的异常情况，就这样，散会。
|
 |
68
kimi0 2020-06-09 22:16:26 +08:00 via iPhone
坐标巨硬，每次做事故分析必有一项是为什么 test 没有发现这个问题。能在上线前挡住的问题，不要拖到线上搞，大家都轻松
|
 |
69
Illusionary 2020-06-09 22:38:37 +08:00
经常半夜宕机也得分情况吧，如果是偏向硬件方面的故障，那还是运维本身的锅。如果是偏向程序本身的，比如什么动不动 OOM，假死，慢 SQL 过多这种就是开发的问题了，前者可以考虑高可用，后者应该让 DBA 或者开发大佬优化。
|
 |
70
wangyzj 2020-06-09 23:15:29 +08:00
运维这个角色的确很尴尬
解决问题是工作 出现问题要背锅 墨菲定律 测试做的再好也不可能完全避免问题 尤其中国企业都是赶鸭子上架一样的上线 然后开发推责任，运维还没话语权 猜测楼主是非互联网行业 devops 无 无法自己挖坑自己填 |
 |
71
so1n 2020-06-09 23:20:40 +08:00
觉得最主要是应该是出问题直接报警到开发这个功能的人 而不是报警到开发这个报警或者运维这个系统的人
|
 |
72
heart4lor 2020-06-10 00:36:26 +08:00
感觉 DevOps / SRE 是一门很深的学问
 |
 |
73
Anshay 2020-06-10 01:20:48 +08:00
我司运维兼技术大佬每天给开发擦屁股。一堆刚毕业 3 年左右的，各种辣眼睛风格的代码。为什么我知道，因为这事就发生在我身上。当然大佬是别人。
|
 |
74
ericgui 2020-06-10 01:26:20 +08:00
灰度发布会不会好一点？
|
 |
75
XanderChen 2020-06-10 03:57:37 +08:00 via Android
你问问你公司的测试部门是干什么吃的，
未经测试的程序为什么允许上线， 为什么经常半夜跳致命警告， 为什么都经常跳了，还不根据致命警告制定更加完善的测试脚本。 以上。 |
 |
76
timle1029 2020-06-10 04:34:03 +08:00 1
@ly4572615 #8 在亚麻你敢不接，30 分钟之后就是你老板接，他要是不接 30 分钟之后就是他老板接，一路往上。你觉得谁敢不接么
|
 |
77
sampeng 2020-06-10 07:47:54 +08:00 via iPhone
作为 10 年开发，也是跟楼主一样的疑惑我就转了运维，看看到底怎么回事。然后每天我的日常吐槽就是：
这个接口为啥这么慢？研发干嘛吃的？ 这个接口我加了机器还是倒置机器 cpu 这么高？研发干嘛吃的？ 这一群服务什么鬼，天天 5xx ？研发干嘛吃的？ 晚上有活动，我又被电话打起来了，什么？这么简单的问题怎么暴露到线上去了？ 横向纵向扩展呢？数据库读写分离不支持？消息队列又 tm 堵了...机器都没法加了，加了数据还是甭掉…研发干嘛吃的？ emmmmm…现在，我又想去做研发了… |
 |
78
namelosw 2020-06-10 08:16:51 +08:00 via iPad
凡事都靠 SRE 的团队和凡事靠 QA 的团队一样，都是有问题的。理想情况运维应该只看看基础设施网络问题就好了。
大部分问题应该在开发阶段弄好而不是找个某些角色当垃圾桶兜底。 |
 |
79
cmaster 2020-06-10 08:33:09 +08:00
管理问题，换个领导
|
 |
80
cheng6563 2020-06-10 08:44:51 +08:00 via Android
我司不配笔记本，也不允许公司电脑挂机。下班后处理不了任何问题。
|
|
81
barrysn 2020-06-10 08:58:35 +08:00
@index90 问题很多，业务变更可能是开发问题， 也可能是运维问题，也可能是流程问题，也有可能是资金问题等等
并不能确定是哪里的问题， 其实楼主说经常性看到运维半夜处理紧急问题，这个应该说明 公司内部肯定是有问题的，但一直没有处理或者没有更好的处理办法， 业务变更是我猜的，还有可能是跨境业务 |
 |
82
lincolnhuang 2020-06-10 09:18:01 +08:00
@murmur #11 马路上有环卫工，所以我是可以乱丢垃圾的，不用我操心
|
|
83
lincolnhuang 2020-06-10 09:19:30 +08:00
@Amance #28 您的理解，运维岗就是半夜起来给开发擦屁股的吗？
|
 |
84
exploreXin 2020-06-10 09:24:49 +08:00
只有 DevOps 能够救运维，也只有 DevOps 才能够救开发。另外要注意一点，是团队基础设施达到 DevOps 的水平，才叫用了 DevOps，而不是公开宣称采用 DevOps，这两个看上去差不多，但却是一个天上，一个地下。
|
|
85
lincolnhuang 2020-06-10 09:24:55 +08:00 1
其实主要是管理问题，不过楼上那么多开发说写 Bug 是为了运维不被优化，真的是笑掉大牙。这个帖子，真的让我感受到了部分开发内心的满满恶意。。
|
 |
86
salmon5 2020-06-10 09:30:25 +08:00
来 100 个产品经理，每天 100 个不同需求，“怎么实现我不管，老板要这样”，别让楼上的某些开发下岗了
|
|
87
murmur 2020-06-10 09:34:54 +08:00
@lincolnhuang 不是给开发擦屁股，但是你没法保证系统百分百稳定运行，总要有人值班，是开发还是运维值班只是个头衔而已
|
 |
88
JRay 2020-06-10 09:51:35 +08:00
项目刚刚开发完，一遍都没测过，老板直接喊给客户部署了。
我有预感会经常半夜打电话来 |
|
91
Amance 2020-06-10 09:59:13 +08:00
@lincolnhuang 那就是管理的问题，代码不审核，随机提交。明显的问题让你来擦屁股的话，说明你你还不配当一个合格的程序员。如果审核了除了问题，就不是擦屁股，那就是你运维分内的事情，程序都给你弄好了养着你天天喝茶出来怼人么？
|
|
92
yuanbo6 2020-06-10 10:55:02 +08:00
@dany813 不少，单是我主要盯的项目就有几十条定制。
按照正常来说我们在实施阶段开始之前就会给用户部署一个测试演示用的产品，并提供产品功能清单，然后开始用户体验，项目经理会开始进行需求调研并收集整理。我们这种定制情况其实还好，毕竟是从实施开始之前就在进行规划工作。但是要命的是实施阶段结束已经上线运行之后用户提需求。 这种需求我们很头大，但是不得不做（用户来头大，无论是经济价值还是政治价值都很高）。 根据我司的项目管理模式，在实施阶段过去之后主要由我们的实施运维交付团队以及商务团队（我这边的用户直接是销售总监对接）和用户做对接，而非上面提到的项目经理。用户此时提出的需求要么是直接和销售总监说，要么是直接和我的团队说。（当然我和我们的销售总监关系还是很不错的，他人也靠谱，沟通起来没啥障碍，这是整个项目团队内部的事情）。我们会先行讨论一下用户提出的需求，第一是否合理（不合理的我做了干嘛？这是有教训的，用户那边有个 NT 提过倆个需求上线之后一星期左右他的领导觉得界面看起来乱要我们撤掉，以后处长级以下领导的需求我们基本不听，因为底层科长级别无法拍板），如果合理，那必须要做（从侧面也说明我们的产品不贴合用户实际需求，也是推动产品进步）；第二看技术是否可行，很多 NT 用户我怀疑是科幻片看多了，天天拿着变形金刚的标准要求我一个可达鸭，我可达鸭真的办不到啊，换谁都办不到啊……一旦以上两点有问题，这时候就需要关门放销售总监出马交涉了（感谢上天赐我一个靠谱的销售，而非挖掘机）。 好的，方案合理性和技术可行性都通过了，一个电话炸到研发总监 /组长 /马仔那里（具体找谁这个要自己把握尺度了，反正我都熟悉……）：喂？老板 /大哥 /兄弟，有定制要做了，需求是 XXXX，方案大概是 XXXX，流程我们这边初步设想是 XXXX 。对方心里：艹，又来工作量了。对方表面：好的，我们安排一下。 故事转到了研发部门。 研发部门会根据所有的开发进度进行定制开发周期评估和排期，有些项目动不动就加急（没错就是我的项目），那没办法，经济因素和政治因素都在那里摆着，研发 leader 们也不傻，就是大兄弟们辛苦。开发完之后测试组三轮测试，成果物发往现场。我们这种大项目一般都有个小型的测试平台专门用来测试新定制或者什么东西的，部署上去，模拟环境测试一周左右，和用户进行沟通，定个晚上开始部署升级。小升级其实还好，大升级就需要知会一下研发兄弟们了，毕竟有些事情测试一千遍没问题他真的会在现场第一遍点击运行就出问题（测试部门的绩效靠我提升，研发兄弟的死敌黑手党）。出问题了 call 人，不出问题给用户留言汇报。 |
|
93
yuanbo6 2020-06-10 10:57:57 +08:00
@dany813 定制部署之后，内部开始评估，这东西能成为标准化吗？？？评估结果 1：只有这项目这个 NT 用户有这个需求。那么成果物单独作为分支进行保留，后续如果有其他 NT 用户要用，拿出来改一改继续用。评估结果 2：这功能确实我们没想到，确实贴合实际使用情况，拉上产品、架构一起把他扔进下一个版本做基线程序。
|
Select Language