这是一个创建于 292 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题，大家有没有类似经历，有没有什么需要注意
 |
1
kkk9 292 天前  19
1day: 😁
2day: 😆 3day: 😃 4day: 😐 5day: 😑 6day: 😒 7day: 😓 8day: 😔 9day: 😠 10day: 😣 11day: 😤 12day: 😡 13day: 😡 ......... 28day: 29day: 😵 30day: 😇 |
 |
2
ghwolf007 292 天前
每个公司情况不同 做好扶着研发写代码的准备 额外学习的就是更多 linux k8s 中间件 监控 等等 比较杂
|
 |
3
randm 292 天前
要么问公司的运维，要么看 BOSS 上的要求。体量不一样，要求千差万别的。
|
 |
4
ixixi 292 天前
做过银行的部分运维 感觉运维这活太脏了
日常得查阅不同厂家开发系统的 log 代码都是屎山 log 更是** 给他们提 bug 好麻烦的说 🤣 不如安安静静写代码 |
 |
5
defunct9 292 天前 1
运维能得到自由，开发不行。
|
 |
7
nise 292 天前
还是要回到经典问题，要懂业务，运维开发的业务就是运维，首先要懂运维
|
 |
8
DAPTX4869 292 天前
两块坑 一块踩
|
 |
10
xiaoshancom 292 天前
运维需要懂业务整体吧
|
 |
12
fliter OP @xiaoshancom 应该知道怎么样部署就行了吧
|
 |
13
Ayanokouji 292 天前
运维开发不还是开发吗，不就是 devops 平台开发吗。
注意点就是 技术差，不适合干这个业务。毕竟业务就是围绕开发和运维进行的。 |
 |
14
oooolongtea 292 天前
bash script, jenkins
大家可以继续补充 |
|
15
oooolongtea 292 天前
@defunct9 怎么说？
|
 |
16
network127001 292 天前
脏乱差 快跑，安心做开发写 bug 不好吗
|
 |
17
yyttrr 292 天前 1
各种云的使用与折扣，各种产品适合什么场景
|
 |
18
mightybruce 292 天前 6
传统运维开发是基于 ansible 和 python 以及一些监控系统来做的
k8s 运维开发 需要懂的很多，V 站上的人多数都不是做这个的，回答真是。。。 k8s 基础命令行操作 kubectl 以及各种概念和资源对象必须懂 k8s 基础之 client-go 开发以及基于这个做一套 k8s 管理系统 Operator 开发 这个因各种公司需求来做 各种 operator 是必须要会写的，才能完成一定的运维自动化 其次像 csi, cri, cni 插件开发 需要懂 运维监控系统 开发 像传统的 zabbix 有的公司在用， 小米和滴滴的 open-falcon nightgale 的开发 prometheus 采集自定义指标这些 |
|
19
defunct9 292 天前 2
@oooolongtea
@fliter 很多程序员的思维里，网络就是一根网线，完全扁平的。其实中间的设备多了去了，各种控制层。dns 的，bgp 的，tcp 代理的，端口复用的。只有运维才能从前到后把所有的环节串起来。能串起来就能获得自由，不会被拘束于某个点。 翻墙简直就是随便搞搞的东西了。 |
|
20
mightybruce 292 天前
另外说一句，能做好运维开发的都是大公司， 微服务治理和运维紧密相关。运维系统没有自动化是管理不了几百的微服务、几百台服务器的。运维监控平台是很重要的。
|
 |
21
yongp 292 天前
别转了，不如撸业务代码，更有价值
|
 |
22
kemo 292 天前
上面的人都说开发比运维更高人一等，可公司真正遇到事情，先裁的是开发而不是运维
|
 |
23
guanzhangzhang 292 天前
不说具体技术栈，主要注意就是思想，我同事
- 例如 py 删除文件是 os.system("rm -f xxx") - 另一个运维开发同事是 go 项目里，ping 检测对端主机存活也是调用系统命令，在我换漏洞更少的基础镜像后，他业务就炸了 - 另一个同事 dockerfile 不存档，覆盖远端仓库上镜像不提前备份远端镜像 - 其他好几个同事排查客户现场问题，查问题不总结已经排查的过程和环境信息，全部零散的发在群里，没有总结，查完就找拉别人 - 工具来源，压缩包啥的都不写注释，下载或者编译完后就用  |
|
25
mightybruce 292 天前
运维是一个非常吃经验的行业， 这一行的确有些人是越老越吃香。不过现在运维也都需要懂开发， 不会开发的运维的效率是不高的。
|
 |
26
mzfbwu 292 天前
自动化：ansible 、ci/cd 、cmdb 、流程工单系统、salt
云平台：各大公有云平台的产品、openstack 网络：cdn 、dns 、域名管理、nginx 容器化：k8s 、docker 监控：zabbix 、prometheus 、elk 还有一些配置管理，数据库相关的可能也涉及到，但是我并不太熟悉，欢迎其他朋友补充。 |
 |
27
tokoy 292 天前 2
咱是运维开发，应该有资格说一些：
你得学会 1. k8s,会网络，会各种数据库，会 CICD 工具，熟悉各大云厂商云服务，会 Prometheus 且最好熟练掌握一套完整的监控架构。---这些属于运维层面。 2. 熟悉业务架构，会部署业务服务，出问题你能第一时间知道或者通知到相关业务的负责人。--这些属于业务层面。 3.会 python 、go 语言，简单的你要能独立开发自动化工具或者脚本，高级一点的你需要配合前端开发运维平台，如果你会前端那更好了。 以上都会的话，恭喜你，运维开发入门啦~ |
 |
28
salmon5 292 天前 2
横向广，纵向浅。性价比肯定没开发高。
拼代码肯定不如开发，你想想，运维平台能有多少用户？（几百几十？并发几个？）能有什么复杂的逻辑？能有多大的数据量？ |
 |
29
dezou 292 天前
@guanzhangzhang 这个删字为什么有点绿
|
 |
31
uncat 292 天前 1
对于关键服务的服务器，有效的备份系统是保证长期（几年到几十年）运行很重要的一环，这里面会有备份策略，成本，有效性的考量。
|
 |
32
coolworker 292 天前 via Android
|
|
33
coolworker 292 天前 via Android
@kkk9
|
 |
36
YaakovZiv 292 天前
要看你去啥样的公司，如果是华为这种，需要小心的就是流程规范了，和我一个项目组的一个老哥，就因为改配置的时候直接修改，没备份，没走任何操作流程，也没做任何邮件通告，直接被开除了，属实让我震撼了很久。我还以为要把我连带开除，我当时才刚入职。那个老哥走前和我们吐槽，他说，”配置改错了再恢复就行了。“。 实际上不能，恢复期间会被按照业务故障计时。
我感觉技术上没有太大的难度。 |
 |
37
FlytoSirius 291 天前 4
前面说了不同规模的公司, 运维所具体的工作内容和具体的技术栈差别很大.
我尝试理下 DevOps 所需要的: 基础的大方向, 这些应该和公司规模及技术栈没太多关系. 硬的: 1. 一个操作系统方向[Linux/Windows] 2. 一门脚本语言 [Shell/PowerShell] 3. 一个业务开发语言[Java/Python...] 4. 一个配置管理工具[Ansible/Chef/Salt ...] 5. 一个基础设施即代码工具[Terraform, Cloudformation, CDK 等] 6. 一个公有云平台/一个私有云平台/一个容器化平台 7. 一个 CI/CD 平台 8. 一个监控系统的应用 9. 一个日志系统的应用 10. 一个备份管理系统的应用 软的: 11. 一些网络知识 12. 一些安全知识 13. 一些业务连续性知识 14. 一些业务系统运作的架构知识 15. 一些各层面所需的测试工具和知识 16. 现代应用和基础设施 部署和管理的一些思路和思想[基础设施即代码 IaC, 容器化, 应用发布模式 ... ] [对这些的理解会直接影响如何应用具体技术进行工作]. 我就先想到这些.其他朋友再补充. 而且, 这其中每一条应该都可以展开为一个知识/技能体系. |
|
38
FlytoSirius 291 天前
@YaakovZiv
这是那个 Team 就没有太按照 DevOps 的方式来运作吧, 他还有很重的之前 Ops 的思路. 否则以代码驱动的配置, 是一定会走 git 的, 再有个一般性的 review, 被同意再进行 修改配置代码的部署. 直接上去改配置绝对是 DevOps 的大忌讳, 因为会导致实际环境和代码部署的环境不一致. |
|
39
uncat 291 天前
@FlytoSirius 挺认同的，特别是上到一定的规模，且业务本身对质量有很迫切的需求。哈哈哈，有这样的团队介绍一下吗，我要去应聘
|
 |
40
hongyexiaoqing 291 天前
@salmon5 内部系统并发是不高，但是业务复杂度每个公司不一样，不一定比业务研发系统复杂度低。
|
|
41
FlytoSirius 291 天前
@hongyexiaoqing
个人认为, DevOps 并不一定就要自己研发相关系统, 毕竟大部分公司关注的是公司层面的业务系统, 所以至于 DevOps team 是使用的自研系统还是广泛使用的系统, 从管理层看是不太 care 的. 能自己开发给其它 DevOps 使用的系统自然是高级 DevOps 能力的体现. 但楼主更关注的是如何开始 DevOps 方向, 而不是 DevOps 这个方向的高点在哪里. |
|
42
mightybruce 291 天前
@hongyexiaoqing 运维开发的确没那么简单， 业务开发也不要太觉得自己并发多高， 很多非核心的部门的那点并发真没多少，复杂的 k8s cicd 工作流 v 站上没几个人提到，
云原生配置可编程之 KCL, cuelang 和 kubevela 这些项目在国内外也是非常火 |
|
43
salmon5 291 天前
@hongyexiaoqing 运维开发、开发各有千秋吧。
一般运维开发单兵能力强一些（全栈），开发很多是一招鲜（ ctrl+c,ctrl+v,CRUD ）。 |
 |
44
oakcdrom 291 天前
这是开发卷不懂了，又卷运维来啦？？？在你那个坑里呆着吧，毕竟很熟悉。。。就别往另一个坑里掉了。。
|
|
45
defunct9 291 天前
要严格按照 devops 的流程走，这种话简直就是扯犊子。除非是特别大的公司，各司其职才可以这么干。
举两个例子：一是我们团队 4 个人正在吃午餐，oracle 数据库挂了。流程个 P ，所有业务都挂了，当时用一个手机重启了服务器。搞流程，那么背锅的就是自己，1 个小时起步。第二个刚发生的，爱名网 dns 解析不太稳定，想迁移到阿里，一改 ns 记录，爱名网把所有解析记录都清零了，转移的时候你根本无控制权，想无缝转移，关键你没有控制权啊。弄流程，3 天起，锅你背吧就 |
 |
46
maxwellz 291 天前
已经想转开发了
|
 |
47
42is42is42 291 天前
|
 |
48
Mistyrainjn 291 天前
不如直接做开发 ，运维开发 主要要懂业务 这种还是比较难的。
|
 |
49
liuliancao 291 天前
主要还是代码 因为运维的部分 其他人会帮你 cover 需求慢慢做就能理解运维的很多需求了 说白了 都会转化成对应的算法问题 你要能提出一些想法并且解决这些问题 另外常见的而 cmdb 工单系统要有一些自己的思路和见解 至于 k8s 有的公司招聘时候会写 那么搞个 CKD 类似的 也是不错的
|
 |
50
Alias4ck 291 天前
我想到了一个库 https://github.com/bregman-arie/devops-exercises
哈哈哈哈 |
 |
51
ptrees 291 天前
开发做这个应该不难吧.
可以了解一下各处的性能瓶颈什么的,应该有点帮助 我觉得运维的工作之一就是合理分配资源,然后保持稳定运行 |
 |
53
edisonwong 291 天前
运维开发也算半个运维，忠告就是：1. 对于删除逻辑（无论你是代码，手敲命令，定时任务）一定要谨慎，确认你执行的范围，确认备份 2. 尽可能趁人全的时候变更，有问题大家还能一起恢复 3. 养成备份习惯
|
 |
54
tiedan 291 天前
都是运维转开发的，没见过开发转运维的。。 从大火跳进油锅
|
 |
55
xiaoming123 291 天前
先考一个 RHCE 吧，考试内容涉及上面说的 ansible 等等，特斯拉亚马逊 jd 上有持有 rhce 证书优先录取，想要报名的话可以看我的帖子便宜出
|
 |
56
pzict 291 天前
以前公司的运维系统的开发语言有 php, python, go, ruby, 除了业务开发、IT 系统、安全类的系统，其他的各种系统似乎都是运维团队开发的，不过那几个开发只做开发，不负责运维。原先有 4W 台机器，团队差不多 70 个人，后来降本增效，各种云，docker 化，差不多 2W+机器，还剩 30 人左右。现在看，那帮家伙还是蛮生猛的
|
 |
57
summeryun 291 天前
运维苦，开发 996 ，运维 7*24
|
 |
61
ppsen 290 天前 via Android
运维开发比 java crud 开发杂，也比 crud 难一些。做什么，都要把稳定性放在首位。
|
 |
62
a663 128 天前
@FlytoSirius #37 都满足，但是一年前转了纯开发，运维受限制太多了，不想受到各种限制+束缚就死命转了开发
|
|
63
FlytoSirius 126 天前
|
Select Language