做了三年的 java 开发,但是都是从别人手里接过来继续完善,改改 bug,现在也在从头做一个项目,开到详细设计阶段;但是感觉自己的 java 技术可能有点落后,在考虑明年转做 python 自动化运维,和运维相关的工作,因为这三年除了开发之外的工作就是实施,运维,linux,solaris 操作系统都会一些。
1
lgpqdwjh 2017-10-13 09:50:59 +08:00 2
就目前的招聘市场来看,java 求生比运维要强很多, 为什么我这么说?
谈谈 python 自动化,一般公司其实并不需要, 因为已经快 2018 年了, 众多服务已经打包好了, 所以目前比较吃香的运维职业系属 “开发运维”、“存储运维”、 “平台支撑运维” 等,这些都需要一定的编码能力并且要对运维流程、管理非常了解才能非常好的支持到开发或者说非常好的完成厂里的指标。 那么,既然都是编码,java 可以落后, 做运维就不一定会领先别人? 从学习的角度来讲,我建议是要多学多看,不要被职业所限制。 当然如果你确信你要做运维,好转(只要你肯努力,肯实践)。 |
2
Tinet 2017-10-13 10:16:53 +08:00 4
千万不要入运维的坑,吃力不讨好的职业
|
3
lixm 2017-10-13 10:20:49 +08:00
为什么不用 java 做自动化运维呢?
|
4
zgbgx1 2017-10-13 10:21:04 +08:00
为什么 不好好做 java 了,待遇应该更好吧
|
5
topbandit 2017-10-13 10:27:29 +08:00
大多数人都会说,运维是背锅侠
|
9
xiangdong OP @lgpqdwjh 谢谢,我也不确定自己现在是不是开发运维,就是有开发,也有运维的工作,我们也有自己的平台。主要语言就是 java,shell 写的少。
|
10
HarrisonZ 2017-10-13 10:40:43 +08:00
运维自动化路很窄,市场需求小。还是做开发吧。如果真的想搞相关的就去研究 PaaS,golang,k8s,容器技术,这些才是未来,然后求职就只有云厂商或者有意做专有云的公司
|
12
8355 2017-10-13 11:49:04 +08:00
简单说个比例 一个公司 30 个开发 可能只有一两个运维 管理不了几台服务器 你还不如做一个可以运维的开发 一般规模的公司对于这样的人都是按小领导培养 毕竟服务器不能随便给一个人是吧.
|
13
8355 2017-10-13 11:51:20 +08:00
还有就是以你 3 年工作经验来说 linux 你又了解多少. 如果非常了解 只是需要学 python 帮你实现自动化运维的话, 那应该学 但你如果 linux 也不是很熟悉 一边学 python 一边还要研究 linux 进度慢不说 还痛苦
|
14
unbeau 2017-10-13 11:51:59 +08:00
运维是大坑
|
15
lihongjie0209 2017-10-13 12:01:11 +08:00
最近打算写一些脚本来做自动化服务, 大概说说我的感受.
1. 首先排除 Bash, 功能太弱, 可读性太差. 2. Python, - 首先 Python 的版本问题. 在 Centos6 中 Python 是 2.6 的, 如果你想使用 Python 的一些新的特性, 最起码应该是 Python2.7 加一些向后兼容的性的库, 比如 future 库, 不然你会在 byte/str/Unicode 之间备受折磨. so, 使用 Python 的第一个条件是使用 Bash 来维护 Python 版本, 你不可能每台服务器都手动装 Python. - 其次, 包管理. 同样的, 你想让自己的生活好一点, 那么你就需要使用一些第三方的库来简化一些原生的脚本, 那么你就涉及到了使用 pip 来管理 Python 的第三方包. so, 使用 Python 的第二个条件是使用 Bash 来维护 Python 的第三方包. 当然你可以说: 我只用 Python 的原生库, 不需要第三方依赖, 减少维护工作. 当然你可以,但是恭喜你, 你开始重复造轮子了, 而且这些轮子都不能复用, 所以你每次都只能把以前的代码 Copy 过来, 写出了真正的"脚本". 比如你想写一个小爬虫, 那么你是用 requests+BeautifulSoup/Lxml 还是原生的 urllib + dom 解析库呢. 从这个例子中可以总结出来: Python 并没有简化运维这项工作. - 最后 Python 语言本身的问题. Python 语法确实接近自然语言, 而且提供一些方便的内置函数, 写个 Demo 确实很漂亮, 可是当你一旦开始写真正的项目, 你就会发现动态语言带来的问题, 前几天打算写一个 Python 脚本调用 Bash 命令, 下面是这个函数的参数列表: ``` class subprocess.Popen(args, bufsize=-1, executable=None, stdin=None, stdout=None, stderr=None, preexec_fn=None, close_fds=True, shell=False, cwd=None, env=None, universal_newlines=False, startupinfo=None, creationflags=0, restore_signals=True, start_new_session=False, pass_fds=(), *, encoding=None, errors=None) ``` 请数一下这个参数列表有多少参数, 请告诉我这叫优雅? 参数列表一旦变长, 参数间的组合就有很多可能, 而且还有许多开关参数(布尔值), 导致文档中的许多描述都是: 如果这个参数 XXXX 或者那个参数 XXXX 就会 XXXX. 稍微有点工程代码规矩的人都会避免参数列表超过 3 个, 不然会导致调用者难以使用. 当然我发现有一些在这个函数上的封装函数, 看起来不错, 刚打算使用,发现是 Python3 之后的特性, 我停下写脚本, 开始考虑我这个脚本是否需要兼容 Python2, 如果需要兼容 Python2, 那么我就需要把我服务器的版本升级到 Python2.7, 然后我就需要维护一个 bash 脚本管理 Python 仅仅是为了一些新特性. 总结: Python 并没有减轻一些运维负担, 而是把更多的负担交给了开发者, 包括包管理以及语言兼容性. 3. java java 作为运维目前还在考虑中, 但是可以知道的是开发者并不需要关心包管理以及语言兼容性的问题. |
16
artandlol 2017-10-13 13:47:43 +08:00 via Android
大部分是从运维转研发
你却想从研发转运维 运维比较吃香的还是自动化,DBA,微服务。 就是研发运维了 |
17
rocksolid 2017-10-13 13:54:47 +08:00
没有大的项目经验有什么关系,只要基础好照样很多公司要啊,大厂自动化运维要求很高,小公司不需要自动化运维,这转的没太大意义
|
18
bomb77 2017-10-13 14:16:41 +08:00
不好,
想学 python 就学,想搞自动化就弄弄看,java 写的好好的干嘛不写了 |
19
lyao 2017-10-13 15:15:22 +08:00
自动化运维比较系统的还得是以 Chef 为代表的 Ruby 家族. 你有开发基础, 从 Chef 入手会更快一些. 等掌握了 Chef 之后再看 Python 家族. 这样不仅可以补 Chef 的短板, 还可以为后面的 Big Data / AI 做准备. 时代变了, 运维也可以挑战百万年薪咯, 不过也可能是购买力严重缩水造成的 ORZ
|
20
est 2017-10-13 15:31:40 +08:00
这么多楼了没有一个人说 ansible ?
把 chef puppet salt expect pssh fabric capistrano mina 这些秒得渣都不剩。 |
21
xiangdong OP @lihongjie0209 十分感谢,在好好考虑考虑。
|
22
est 2017-10-13 15:36:51 +08:00 1
很多人的自动化运维思维还停留在上个实际的层次:
1. 运行 A 2. 执行 B 现在都是 状态收敛 作为基本出发点了。什么是状态收敛? supervisor: - name: proj_abc - state: restarted 这三行表示最终状态是 proj_abc 被重启 如果 proj_abc 已经启动了,则重启它的 pid。 万一 pid 不存在呢?还得检查 proj_abc 是否已经启动。没启动则启动 然后得查有无 proj_abc 这个项目,没有的话会依赖复制把这个 proj_abc 项目激活 其次也得查有没有安装 supervisor,没有的话连 supervisor 也要安装上 三句话收敛成一个最终状态。 |
23
salmon5 2017-10-13 15:38:18 +08:00
还是老老实实最业务开发吧,自动化运维这个自动化它有很多很多前提,小公司搞不好业务需求也不大,大公司难度大也难搞。
|
24
xiangdong OP @rocksolid 我的开发经验不算多,多数是在写别人架构好的项目,把功能实现,修改程序 bug,完善业务流程,所以总感觉缺点什么,除此之外就是不断的改 bug,一个人负责四五个和平台相关的程序。
|
27
youyoumarco 2017-10-13 16:01:09 +08:00
还是开发吧,几线城市都需要开发,但是运维确不是必须的
|
28
defunct9 2017-10-13 16:04:07 +08:00
运维挺好的,快转吧。
|
30
lolizeppelin 2017-10-13 17:46:39 +08:00 via Android
呵呵 觉得运维的代码好写转运维?
openstack 就是一套运维代码 你可以试试看好不好学 顺便上面扯 Java 的 好好想想有啥运维工具用 java 写的 居然不用关心包管理都出来了 |
31
lixm 2017-10-13 17:56:02 +08:00
@lolizeppelin java 就不能写运维工具么? 我目前就在用 java 写运维工具,基于 mesos 做的 CI/CD,说到 openstack, 现在用的比较多的 ZStack 也是 java 写的,我以前写 Python 的,后来转的 java, 当团队里,水平差异比较大的时候,java 要比 Python 好很多,至少不会相互看不懂代码
|
32
artandlol 2017-10-13 18:33:30 +08:00
@est ansible-playbook 应该就是你说的那种状态收敛
感觉都还是半自动化的,不知 DevOps 能否实现完全自动化 |
33
DoctorCat 2017-10-13 18:35:57 +08:00
就是去做运维业务开发而已,不用想太多,技术都是相通的。
一般的码农岗位都是 CRUD+前端,运维开发有机会去了解高可用系统架构、网络架构、IDC 建设。 其实,还得看个人。基本的 CRUD+前端+高可用架构方案,都了解差不多了,以后 Web 开发领域做啥不行啊,纯业务导向罢了。 |
34
DoctorCat 2017-10-13 18:39:14 +08:00
建议站在技术栈的角度来思考问题提升技术认识和格局,而不是具体的“ XX 开发”岗位
|
35
lolizeppelin 2017-10-13 18:47:22 +08:00
bash 还能 socket 编程呢
python 做运维语言优势比 java 大多了,不然为什么 Linux 用 python 来管系统而不是 java?为什么 python 能取代 perl 在系统里的地位? 至于包管理, 按 linux 的规范用就应该用系统包(rpm、dep)来管理,根本就不该用 pip,用 bash 来管就是更加错误 Popen 那个本来就是底层调用有那么多东西要考虑,你不想考虑那么多完全可以用只有几个参数的执行方式. 这个和 python 没任何关系,无论你用什么语言做系统调用都一样 这就好比 openstack 一个组件的配置有几百条,你能说这个组件设计得不好居然有那么多参数可以设置? 动态语言的问题参数的问题其实没那么大,一定阶段确实会不适应,代码架构够好就不是大问题,可以学 openstack 怎么做的 --- “ Python 并没有减轻一些运维负担, 而是把更多的负担交给了开发者, 包括包管理以及语言兼容性.” 在你看来开发和运维是隔离的, 如果运维和开发是一体的?负担在哪有毛线区别? 至于兼容性..哪有那么兼容性..系统管理老老实实用系统自带版本,主流系统上只有 2.6 和 2.7,要兼容的地方根本不多,跨系统的兼容性其他语言好得到哪去?除非一开始上了当用了 python3 --- java 有 java 的优势,但不能因为你们的技术栈是 java 和 java 的部分优势就说 java 在运维上比 python 好 最后,就算要取代 python,目前看也更偏向 go 而不是 java |
36
privil 2017-10-13 18:57:22 +08:00
|
38
lolizeppelin 2017-10-13 19:10:41 +08:00
现在不知道 以前看 ansible 代码的时候,那个异步执行的方式看得我蛋痛 233
|
39
bobuick 2017-10-13 19:15:10 +08:00
很多说为什么不 java 的同学。我估计 lz 是属于 java 一直在做 crud 的活,纯横向堆框架内的代码是最无趣的了。转下运维蛮好的,让自己看到更多,而不是以为运维就只写脚本
|
40
ik 2017-10-13 19:41:03 +08:00 via iPhone
运维确实是背锅侠
|
41
lihongjie0209 2017-10-13 20:30:04 +08:00
@lolizeppelin java 打包好之后确实不需要包管理
|
42
lihongjie0209 2017-10-13 20:34:38 +08:00
@lolizeppelin bash 管理软件包就是指用 rpm 和 yum 写 bash 脚本, 关于参数问题, Popen 的例子可能不太准确.
|
43
lihongjie0209 2017-10-13 20:37:24 +08:00
@lolizeppelin 目前我也在探索如何使用较为轻松的使用 Python, 现在主推 Python3 的呼声太大, 导致我在选择版本的时候没有考虑使用场景, 在系统运维方面确实只需要考虑 python2.6\2.7.
|
44
kaneg 2017-10-13 21:29:47 +08:00 via iPhone
最近在用 ansible 做了一些自动化安装部署方面的工作,其中组合了 shell,playbook,以及 python,发现越复杂的状态和流程越能体现出它的优势来。尤其是它的幂等性使 playbook 的稳定性,可靠性和复用性比单纯用 shell 强大很多。当然能用几行 shell 解决的用它是有点大炮打蚊子了。
|
45
lolizeppelin 2017-10-13 21:35:46 +08:00 via Android
java 不需要包管理就和 c 全用静态库一样
window 里的程序也不用包管理啊 但是一旦涉及到依赖那酸爽 linux 上本来就是互相依赖的 java 这种隔离在系统外的没依赖看上去爽 但这种做法是有违 linux 系统管理原则的 |
46
Admstor 2017-10-13 22:50:20 +08:00
15 楼同学是典型的码农思维来理解运维...
实际上做运维根本不可能还给你做不同的系统来维护,你考虑兼容性情况实际上不存在 基础系统必然都是一套,否则每个版本的测试会疯掉 此外 pip??运维的 python 用 pip 管理?这几乎不可能去在实际中使用,或者仅限小范围的测试系统而已,线上系统根本不会考虑 |
47
lihongjie0209 2017-10-13 23:25:16 +08:00
@Admstor 这样啊
|
48
jjx 2017-10-14 04:39:39 +08:00
ls 一些运维不重要的回复让人大跌眼镜
一旦你到几十台服务器以上,而且存在频繁更新, 让开发或是技术负责人来兼任运维,没有专职运维, 这是要坑死人的节奏 所谓不需要要运维,只是因为还不到这个规模, 开发,技术负责人在顶锅而已 |
49
pepesii 2017-10-14 11:16:46 +08:00
我看就是技术栈的差异而已,没有什么 python 自动化运维之说,你换个语言不一样运维嘛;
开发所关注的点在业务层,某些框架,运维关注的点在 ci/cd,监控,快速扩容,以及服务的稳定等方面; 而且运维在现在越来越向云方向靠拢了,更多的是去关注在 openstack,docker, k8s 等方面了。 赞同 48 楼! |
50
wuyuchenshishabi 2017-10-14 11:17:34 +08:00
不是说运维不好,但是一般都更喜欢做开发吧。
|
51
a1044634486 2017-10-14 15:32:28 +08:00
运维技术更新太快,感觉开发更新没那么快
|
52
ywgx 2017-10-14 17:24:06 +08:00 via iPhone
楼上的运维都别吵,让 https://xabcloud.com 替代你看看,看看还有多少工作需要你 😄
|
55
Admstor 2017-10-15 17:14:51 +08:00
@ywgx 看了一下介绍
你这主要功能不就是堡垒机+简单的性能统计 自动化部署根本不存在 自动分发上下线代码也需要自己来做 弹性调度和故障预警都没有 腾讯云卖了 5 分,阿里云卖了 11 份 我觉得贵司的产品说代替运维,未免太过自信 |
57
fengxuejianshi 2017-10-18 20:25:39 +08:00 via iPhone
弱弱问句:有人像我一样用 php 做运维吗?
|
58
dayinfinte 2017-10-18 21:42:45 +08:00
运维出身,只能给的建议是,
1. 提高 python 的开发水平 2. 尽量学习前端知识 基本上述这两点到达了, 即使没有自动化运维工具,自己也可根据线上环境开发出来, 当然至于是否开发就看你们的实际情况了。 |
59
justff 2017-10-25 08:09:57 +08:00
@fengxuejianshi 厉害了老哥
|