请大家谈一谈自己的看法，关于运维这个岗位

[WhiteBase]

是这样的，自己志向还是做开发，在学校里做的大多数事情也是开发相关的。但是现在现在一个心怡的公司的开发岗位已经没有了，但是还有运维岗，有些技能点还是匹配的。
于是，在网上查了一下，知乎上的说法普遍不乐观，认为国内大多数的运维最后都是在做操作员，会把自己的路越走越窄。所以想了解一下各位有经验的前辈对于运维工作的看法，是不是真的会丢掉自己的开发功底，把这路越走越窄？我是喜欢*nix，但是功力没有深到可以做系统开发，又不想限制自己以后的职业道路。
如有错误的认识，也请各位不吝指教。

[9hills]

我厂的运维更多的是应用运维，level高的运维已经偏架构了。举个我问过别人的面试题，可以说这就是一个现实的case，给你一套系统，给以一批数据，你需要给出需要多少台机器，这个系统的基本性能如何。这都是运维需要考虑的。

问题：

假如我们目前有一个3副本的分布式存储系统，单机有序（将网页按照URL顺序存储在SATA盘中），存储的最小单位是10M的Block（读写都以Block为单位，不能只读一条网页，必须将整个Block加载到内存中，然后读取其中一条网页，并且Block从硬盘载入到内存的速度远远慢于从内存的整个Block中找到其中一条网页并返回的速度）。

内存中有种算法可以瞬间定位URL在哪个Block中（这个是另外一道题的考察点，此题可以忽略）


问题来了，我们有1000亿网页，平均URL长度是50B，平均页面大小2KB。使用的存储机器是3T*8的SATA磁盘，内存64G。

需要多少台机器才能满足要求。在使用最少的机器的情况下，整个集群的顺序Scan的QPS是多少，随机Query的QPS是多少。在这个集群没有读写的情况下，内存占用多少，集群按照最大的随机Query的QPS查询时，内存占用多少。


扩展问题：

假如硬盘的周故障率是千分之三，机器8块盘中的一块盘故障，则整机下线。而目前我们的平均维修周期是一周（从机器下线，到这台机器上的硬盘维修完成，并上线）。

那么请问我们这套系统除了线上的机器，还至少需要多少备机，才能保证不受硬盘故障的影响？

[arachide]

分大中小

1 大－ 基础IAAS传统运维多但也要自动化（linode do都是几十人伺候全球几十上百万客户）
2 中－ 中型公司善用云 高度定制自动化是公司的核心竞争力之一
3.小－ 微，小型公司，个体 多用webservice 最好自己不写一行代码

以后后端不知是写php脚本和前端交互
多指自动化运维脚本开发和写大数据bi分析算法
现在的脚本程序员要不转行要不淘汰

[rentaro]

"运维"这个词就有问题，涵盖了不少角色，被误解太深，改成平台开发工程师会不会好点，我知道的几位 linux 社区的视野明显不同，编程功底远超普通程序员。

[invite]

别小看运维， 运维很多时候需要经验。

而开发，说实话，如果上不去，一辈子码农，还没运维好。

[mN71eOOprFyMsnPx]

工作8年，一直是运维 + C++开发，悄悄告诉你这样的组合很爽。
我的经历体会就是纯粹的做开发的同事，思维好窄！

[twl007]

@wolfdolf 现在教授的一个毕业的学生靠着这个在Housyon找的10w刀的～ 信不信随你…… 反正真的就这么多

[twl007]

@wolfdolf Houston 打错……

[Admstor]

看不过少开发人员早期弄些一键安装包搭起来的系统,一塌糊涂
最后丢给运维擦屁股

可能那些开发人员这个时候就开始甩包袱,老子又不是运维才不管后期的事情
当初怎么没仔细去研究研究整个系统的结构呢?

yangtuo同学,你说有几个公司需要自己架设服务器,那么又有几个公司需要自己写代码库,开源产品一堆堆,作为运维我也可以说你们程序员就是复制粘贴而已

简而言之,运维是会随着公司成长越来越重要
你觉得运维对你不重要,说明你们公司根本就没达到一个规模

[xderam]

前两个问题没太看懂.可能水平不太够.MC做的事情?索引? 或者是对业务场景了解的不太深..
最后一个问题还是比较通用的...晚上好好算算..

[xderam]

@9hills 前两个问题没太看懂.可能水平不太够.MC做的事情?索引? 或者是对业务场景了解的不太深..
最后一个问题还是比较通用的...晚上好好算算..sorry 刚刚没有at上.

[twl007]

@Admstor 擦了好多屁股的飘过…… 😭

[banri]

经历+精力

[efi]

@yangtuo 的新马甲是 @pfitsen9 。这是在模仿被你骂的这位 @ pfitseng 么？

[hdbean]

已从运维转开发

[efi]

Jeff Dean就是顶级运维。

[pfitsen9]

@efi 什么意思，我的原账号是 @pfitseng ，被禁言了，早上不能登录了。那个yaotuo注册才几天，怎么可能签到500多天

[Monad]

@ETiV 要是开发同事不知道怎么设计甚至提出挑战，策划会摆出各种数据告诉这个开发为什么要这么做，这么做会带来稳定的活跃还是收入点，这一切都不需要策划和运维沟通讨论任何问题。
所以至少在游戏的功能点设计上，开发比运维清楚。

[ETiV]

@Monad 嗯. 你侧重的是 "话语权" 的问题上, 我说的是心态的问题.
实际上我也没有表示出运维这个角色, 在研发环节上比运营/策划/程序员能有多少分量.

当时我们的研发们, 除了在内网调试游戏外, 几乎从来不登我们自己游戏看的~

另外, 我说的跟研发沟通是指技术上的沟通, 而非游戏运营, 或功能点策划.
"数据库表结构是如何设计的" 这类问题. 毕竟里面牛逼的人还是有的, 多讨教讨教嘛

[nnfish]

楼主担心“ 不做开发，做运维会不会把这路越走越窄”

我的观点是：

1、这个真的需要看人而来，如果是个本向热爱技术，又勤奋并善于学习产品业务、团队合作的人，是会越来越宽才对；
反之，一个不善于学习，不勤奋的人，在什么岗位都是越来越窄

2、开发是一件综合、从长计议的事，运维这个岗位一开始也许跟开发岗位少一些开发工作
但如47楼、65楼所讲，运维这个岗位，其实也是一个非常值得深入耕耘的岗位，
与开发相比，运维会对一个人的产品思维、业务思维、业界视野有更大的促进和提高

顶尖的情况是：
一个优秀的运维人员，往往也是优秀的产品架构师了，是一个能从业务需求直通到产品实现的人

总结：
条条大路通罗马，只要自己足够勤奋和努力 + 一个好的工作环境

[Monad]

@ETiV 那看来就是个体差异了 我们的开发在业余时间也基本不会登陆自己游戏看，运维就更少了。
不过我觉得运维对于游戏的作用还是在于对机器和网络故障的跟踪，快速反馈和处理，真正具体到游戏业务的话反而不是一个运维该接触的。而至于游戏的架构则是开发确定下来的，运维当然可以提出各种建议，但是代码是开发写出来的，开发#理应#比运维更了解这些东西。
不知道你的观点如何。