这里有做产品运维工程师的吗？

[denisyu]

感觉这工种要求挺高的啊， 除了对技术啥都要了解， 还要有很强的沟通和协调能力， 还有很强的问题分析能力。 有没有做这个工作的同学来分享一下经验啊

[hourui]

我的理解，不对轻拍。
1，对OSI 7层模型有深入的理解，能够快速准确定位网络问题。
2，对Linux/Unix命令有着很深的功底，知道如何追踪一个进程在干什么，如何检测机器的健康情况，如负载，流量，IO
3，至少会一门如Python，Perl，Ruby，PHP等的脚本语言，能够开发一些日常运维脚本，深藏功与名。

[denisyu]

@hourui 我觉得你说的这部分的工作偏向于网络， 操作系统级别的运维的， 上面还有数据库， 应用系统的运维， 我估计运维工作其实细分的话应该有非常多的种类把。

[hao0088]

还要熟悉nginx，mysql等主流程序的配置，调优等。话说真要做好了，要求挺高的。

[Sunyanzi]

事实上这个要看公司对运维这个工种的需求 ...

我现在招运维不需要任何前置技能 ... 会操作 windows 并且认真细致能接受轮班就可以 ...

并不需要了解技术 ... 只要你会执行命令并且确认不会执行错你就已经是一个运维了 ...

你并不需要知道这个命令是如何运行的 ... 你只要知道这个命令正确的返回结果就好 ...

转正之前你还要学会看 log ... 但并不要求每行都看懂 ... 知道特定几个关键字即可 ...

如果你会一些技术 ... 写 bat 脚本或者 bash 脚本 ... 我会更加偏爱 ...

但并不代表你不会这些技术就没资格做运维 ...

以及沟通和协调能力并不需要很强 ... 有必要的沟通能力即可 ...

事实上比起轻浮而侃侃而谈的人我更偏爱沉默但踏实干活的人 ...

运维虽然是一个需要协作的工种 ... 但这个协作终归还是大家每人做好自己的一块 ...

一般的沟通只是可以完成维护表上安排给他的工作 ... 告诉别人自己完成了 ...

如果遇到问题知道如何总结问题然后邮件我就好 ...

关于问题分析 ... 我有一个 knowledge base 大家一起维护 ...

团队成长三要素 ... 遇到问题 ... 解决问题 ... 分享经验 ...

一般的问题很容易找到答案 ...

如果想要成为运维组长 ... 并不需要技术实力强别人很多 ...

技术方面的差距充其量就是别人需要查 KB 才能解决你可以当场提供解决方案而已 ...

更加看中的能力是看人 ... 组内分配工作 ... 选择正确的人去做正确的事情 ...

这就已经脱离运维范畴了不是么 ...

其实没必要把这个工作想得太复杂啦 ...

数据库规划与搭建是 DBA 的事情 ... 程序执行与排错是研发的事情 ...

做一个运维 ... 只要保持系统能够正常运转就好了不是么 ..?

[pianai]

工资低一点的产品经理吧

[glancesx]

什么叫产品运维工程师.

[raincious]

@Sunyanzi 正常情况下是这样的。

但出了事故就是两回事了。一类人能立即解决问题然后反馈给研发人员；另一类人得查半天打半天电话，然后叫研发人员提供解决方案。

[Sunyanzi]

@raincious 如果研发运维一体的话确实如可以这样 ... 但假如分属不同部门就不行 ...

遇到一个常见的问题 ... 任何运维都应该在短时间内快速解决问题而不必惊扰研发 ...

如果遇到不常见的问题 ... 一种情况是运维成功解决反馈给研发皆大欢喜 ...

另外一种情况是解决问题的过程中制造了更大的问题 ... 毁坏了现场或者影响了排查 ...

这样本来的产品事故 ... 会完全变成一次运维事故 ...

事实上从流程的角度讲 ... 运维应该是没有权限自己提出解决方案的 ...

对于运维来说只有两种情况 ...

一种属于曾经见过的问题 ... 或者是硬件环境的问题 ... 立即自己处理掉 ...

一种是新出现并和产品有关的问题 ... 应该立即保持现场联系研发 ...

在清晰描述问题之后可以提出自己的意见 ... 我觉得可能哪里出错了可能可以怎样修复 ...

但不管怎样 ... 处理这类问题之前必须得到研发的授权 ... 不能先斩后奏这样 ...

[yyai3]

@Sunyanzi 顶。
纯运维感觉没有成就感，而且有很多的制度约束，毕竟是生产系统～

[gotounix]

楼主应该是想说产品运营吧？运维跟运营是两个概念，运维主要是做好某事，运营主要是某事的结果反馈如何。

[raincious]

@Sunyanzi 我觉得任何一个运维都不应该因为去排查一个问题而造成了更大的问题。

成熟的运维应该能立即判断出自己是否能够解决这次故障，以便选择处理方式。

所以运维方面，没有“保持现场”这种说法，只有“不破坏现场”。

但是要考虑到了，事故的发生很有可能伴随着服务的停止。所以运维的最主要任务不是保留现场，而是恢复服务。在服务恢复之后，再整理证据之类。

当然，其间如果需要的确是必须联系开发人员的。同样，保留日志、程序中详细记录错误信息也是很重要的。



另外其实，在我的经验里，很多故障发生之后，你保留了所有的信息，很可能仍然无助于错误的修复，一是程序可能不是你做的，二是错误的触发太复杂，需要全部dump出来慢慢分析。这时候，首要任务当然是恢复服务。

不过这也证明了，运维还是要有一定开发能力的，至少你会分析日志和dump出东西。所以一楼有得分理所应当。

[kevinv]

@Sunyanzi 不是很赞同你的说法，你的第一个回复在运维工种里面叫做监控运维，你说的运维的定义比较简单，基本上毕业生就可以做，每天轮班啥的，不需要技能。我说下我目前的工作吧，目前我这边有最简单的升级项目、监控程序的设计、系统级别和应用级别的优化、程序架构的调整建议、运维环境的不断改进、针对目前研发上线的项目的漏洞检测。还有就是你说的解决故障，但是我没有保留现场啥的，当然，我也没有破坏过现场，我只是解决故障，从各个角度来分析故障，这个各个角度包括网络，硬件，软件啥的。
我的工作也就是应用运维干的事情，还有基础运维，负载部署机房网络和硬件的。
运维的基本工作是提供高可用的，可靠的，稳定的生产环境供项目运行。当提出解决方案的时候要做好风险评估，当遇到问题时要及时向上级或者部门经理汇报，不能把这件事情埋在心里，毕竟生产环境的一个错误会直接性的导致公司的损失。
在业务方面当然是产品或者项目经理说的算，但是生产环境还是运维说了算。

[akn8]

运维的话楼主可听下teahour最近的这一期http://teahour.fm/2013/07/22/interview-with-shaohaiyang-about-upyun-devops.html

[csx163]

@hourui 谢谢，简历有写的了 ^ ^

[denisyu]

昨天发的帖子今天上来看大家讨论的好激烈啊， 我自己感觉运维工程师这个职位在每个公司里面做的事情差别可能还是蛮大的， 例如我们公司里面有IT部分负责所有硬件，网络，操作系统级别的安装， 部署， 监控， 问题排查以及解决， 但是IT不是很懂我们的应用系统， 所以之前的应用级别的运维工作都是由产品经历和研发工程师， 项目经理和架构师们来解决的。 这种方式经常出现人多了反而问题得不到解决， 经常出现扯皮的事情， 所以现在就想建立一个专门的运维团队来负责应用级别的运维， 从web server, 数据库一直到我们自己产品的应用系统，不过看起来这个运维工程师的综合技术能力以及对问题的分析能力非常重要， 知道什么问题自己可以解决， 知道什么问题需要找研发来解决。

[rrfeng]

高级运维无所不能，低级运维无一所知。

唯汝之所愿尔。哈哈哈哈

[lixm]

在互联网行业做了多年的运维工程师，谈谈我的看法吧。
首先，需要非常广泛的知识，你需要了解系统运行的每个细节，操作系统是如何运行的，原理是什么，网络是如何组织起来的，原理是什么。你们公司的产品是什么，如何运行的，调用路径是什么样的。你需要清楚每一个request进来之后，经过了哪些系统，做了哪些处理，responce是什么样的。

其次，运维要求责任心，任何一个告警都不能放松，即使是半夜收到的。

最后，运维需要体力，加班熬夜什么的就不说了，机房搬机器绝对是体力活，一个2U的机器五六十斤，一天上架个五六十台机器，对体力绝对是个考验，更不要说4U，7U的设备了。

很对人，对运维存在误解，认为运维就只是个操作工，事实上，那不是运维。真正的运维是需要从原理上了解，并且能提出优化建议的人的

[hourui]

“运维开发”，我觉得这样叫更加贴切。

[kojp]

突然想起来, 原来我也是运维攻城师 . . .
兼司机, 搬运.

大部分时间是在巡检填报表.
小部分时间在解决问题
更小部分时间在总结经验和优化现有产品.

[kojp]

@raincious
这就是人手跟人才的区别, 有的公司需要的是一大堆人手. 有的公司需要一两枚人才.