1
SaberJack 2020-11-22 10:29:46 +08:00 via Android
运维路过 周围同事都转开发了
|
2
yzbythesea 2020-11-22 10:30:34 +08:00
AWS 还提过 SRE 方法论?不应该都是 SDE 一锅端了吗?
|
3
opengps 2020-11-22 10:51:58 +08:00
开发转运维应该会比较轻松,毕竟不出问题时候相对自在,但是出问题时候,那可真是各方面来压力
|
4
Illusionary 2020-11-22 10:58:57 +08:00
转运维开发可以,sre 那种,业务运维就别去了。不过很多业务开发的基础都比较差,比如我就遇到过一些开发分不清公网 IP 和内网 IP 的,转运维比较吃力。
|
5
ETiV 2020-11-22 11:06:14 +08:00
看你自己是个啥样工作风格的人
现在的运维工具都相当成熟, 特别企业基础设施在 XX 云之类的,平日的编程工作基本上就是面向云平台的 CRUD, 非编程工作就是写各种配置文件。 对我来说,这些工作内容就没有那种解决难题的那种快感,没意思… 当然你要是有能力往像 kubernetes 提交核心代码,那就另说了 |
6
coderluan 2020-11-22 11:13:58 +08:00
楼主你不用感觉, 直接去招聘网站看看平均薪资就可以了.
|
7
locoz 2020-11-22 11:50:30 +08:00 via Android
想摸鱼就转运维,我碰到过的运维都是闲到天天玩游戏、看小说之类的…
|
8
sggggy 2020-11-22 12:16:40 +08:00
个人经历:公司十年,之前是系统运维,按照《凤凰计划》梳理的经验做;后来照着 google 的《 SRE 揭秘》团队转 DevOps 和 SRE,最近开始打算再重做一次,换个思想照《混沌工程》书里的思想来重塑。
但运维还是要关注到底开发团队的业务有什么特性,这样的特性用什么样的运维方案最合适。每次有遇到研发提需求的时候,基本上都是拉着运维同学直接去听研发的想法,然后才去考虑用什么方案最好。 开发转运维,我倒是觉得没啥问题,运维团队里多一个做过项目的开发人员的思想,容错性会增强,很多。都是团队协作,不至于突然老板就把一个开发孤零零的转成运维。 运维在做解决方案的时候很容易出现一种误区:一个病人来找医生“你看看我这病要怎么治”,医生说“给你一副药你去吃 3 天,3 天后再来找我”,病人说“你怎么看都不看就让我吃药”,医生很快就啪地一声站起来说“我前三个病人都是这样治好的,你也一样!” 针对不同的项目,业务类型,一定要多分析,和项目组的人一起跟上线,跟更新,成熟了之后再慢慢放手。 技术栈方面,倒是有不少可以把玩的东西,想学的一大把。 运维要做出成功,取决于运维的项目是否大成。自己做的特别好,但运维的项目都没成功,简历其实就不是很好看。 |
9
pythonee OP @yzbythesea 哈哈
|