请大家谈一谈自己的看法,关于运维这个岗位 - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
WhiteBase
V2EX    DevOps

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

  •  1
     
  •   WhiteBase 2015-03-07 15:25:10 +08:00 32754 次点击
    这是一个创建于 3878 天前的主题,其中的信息可能已经有所发展或是发生改变。
    是这样的,自己志向还是做开发,在学校里做的大多数事情也是开发相关的。但是现在现在一个心怡的公司的开发岗位已经没有了,但是还有运维岗,有些技能点还是匹配的。
    于是,在网上查了一下,知乎上的说法普遍不乐观,认为国内大多数的运维最后都是在做操作员,会把自己的路越走越窄。所以想了解一下各位有经验的前辈对于运维工作的看法,是不是真的会丢掉自己的开发功底,把这路越走越窄?我是喜欢*nix,但是功力没有深到可以做系统开发,又不想限制自己以后的职业道路。
    如有错误的认识,也请各位不吝指教。
    112 条回复    2023-07-18 15:10:16 +08:00
    1  2  
    webjin
        1
    webjin  
       2015-03-07 16:08:46 +08:00
    好域名需要注册的
    yangtuo
        2
    yangtuo  
       2015-03-07 16:11:41 +08:00
    运维,难道不是程序员的基本功吗?
    WhiteBase
        3
    WhiteBase  
    OP
       2015-03-07 16:16:50 +08:00
    @yangtuo 一些简单地运维操作确实是最好每个人的掌握,但是我比较想了解的是运维的职业发展以及前景,会不会有如知乎上所说的越走越窄这种问题。
    yangtuo
        4
    yangtuo  
       2015-03-07 16:20:11 +08:00
    @WhiteBase 所有没有大难度的职业,不需要长时间积累的职业,容易入门容易提高的职业,都是没有前途的职业,运维就属于这种类型,另外,云计算又给运维补了一刀
    twl007
        5
    twl007  
       2015-03-07 16:25:17 +08:00 via iPhone
    @WhiteBase 往后就是系统架构师 越走越窄…… 你是没碰见过复杂的系统吧…… 不过往后走其实也算是开发了 比如自动化运维 好多东西都要自己实现了 越走越窄只能说方向没走对 最后变成操作员那是要多水……


    @yangtuo 程序员搞运维…… 呵呵~ 会写的就会用? 请问有多少程序员可以自己维护好bind的或者用postfix搞定邮件服务器 我说的不是跑起来而是完善的设置好 能彻底搞明白那些配置选项参数也不是说一朝一夕
    yangtuo
        6
    yangtuo  
       2015-03-07 16:48:45 +08:00
    @twl007 有几个公司需要搞定邮件服务器?这些运维的工作不是没有,但是很少,比程序员职位少的多。所以『运维的工作越走越窄』

    PS:以程序员解决各种见过的以及没见过的疑难杂症的能力(基本功),解决运维上遇到的问题,都只是时间问题(这个时间不会太长)
    zealic
        7
    zealic  
       2015-03-07 16:57:41 +08:00   1
    好程序员 >= (开发+IT+运维+测试)
    只是牵扯到精力问题,才把这些工作内容分化出来的。
    twl007
        8
    twl007  
       2015-03-07 17:01:01 +08:00 via iPhone
    @yangtuo 少么? 并不少 你自己弄一整套exchange起来? 国内不少公司也是自己搭建邮件服务器好么 只是国内很多公司觉得有开发就行了运维丢给程序员了 同学在的公司还在用xamp跑生产环境 这怎么吐槽 而且我也见过程序员兼职运维把环境弄得一团糟或者依据个人口味用少数派linux 完全不考虑后去可维护性系统升级安全补丁问题 一次弄完再不动的即视感 还有就是大部分公司没有那么高的运维需求 但这不代表因为越走越窄 相对的我也可以说写程序是吃青春饭的 这不也是一个很常见的论调 但你就认为程序就是吃青春饭的?

    至于越走越窄那是因为在一个成熟的环境里 所有的基础架构都搞定了 日常运维工作肯定不会太复杂 但是如果从零开始呢 你确定程序员可以很快搞定 而且论解决问题的能力这个不分职业吧 还有有些问题不是说你能力强就能解决完的 程序那么多bug程序员解决起来都要时间何况构建一个复杂系统时候会遇见的各种问题

    还有运维岗位是少 但是人数相比程序也少得多 都是相对而言的
    twl007
        9
    twl007  
       2015-03-07 17:02:31 +08:00 via iPhone
    @yangtuo 云计算基础架构不是运维维护的? 只不过paas把这些工作隐藏了起来 程序员不需要直面了而已 但不是代表不需要运维了 你不需要云计算平台需要
    TimLang
        10
    TimLang  
       2015-03-07 17:04:06 +08:00
    运维蛮辛苦的,手机24小时待命,和开发的人际关系可以参考程序员与产品经理。
    TimLang
        11
    TimLang  
       2015-03-07 17:06:51 +08:00
    @yangtuo 这个真恶心啊,以前招个运维至少要懂虚拟化,现在这个都可以省了。。
    twl007
        12
    twl007  
       2015-03-07 17:11:58 +08:00 via iPhone
    @TimLang 美帝拿到vmware初级认证年薪可以到10w刀
    crazyxin1988
        13
    crazyxin1988  
       2015-03-07 17:12:21 +08:00
    在公司里 我觉得运维组好NB的说
    毕竟要开发一些 自动化的东西~
    datocp
        14
    datocp  
       2015-03-07 17:22:02 +08:00   1
    有点类似网管一样的工作啊。
    既然心怡这公司那首先就要先进去,其它的以后再说。
    工作这东西还是分年龄的,人多岗位少技术要求低最终导致人满为患,很多岗位薪资几百年不变当你30岁40岁时还怎么跟年轻人竞争几千块的岗位。最终还是要不料的学习,不要上班等下班悠闲惯了,最后才发现跟技术脱节了。不过碰到的一些人,不是转销售就是希望自己开餐馆一直做技术支持或者程序员很少。其实能挣钱的行业更多啊,像零售汽配之类的。总感觉年轻人要跳出电脑这个大坑啊。
    echo1937
        15
    echo1937  
       2015-03-07 17:34:05 +08:00   2
    @yangtuo @twl007 做了三年运维了,说说我个人感觉。

    开发就像做砖头的,运维就像砌砖头的,云计算时代,以前的砖头变都成了整面的预制墙,很多IT服务可以开箱即用了,传统型的运维需求大大降低。运维人员流向也从每个公司必备转而集中到云服务提供商。

    然而,云计算服务要求更高的可靠性,安全性,可管理性。从这个角度来说,运维的技术含量不是降低了,而是增加了(有不同意见的可以去谷歌,微软,亚马逊,阿里的运维团队了解一圈)。

    但是传统型运维的岗位确实会越来越少,地位会越来越低,以后云服务提供商会像电力部门一样,保证电网稳定安全运行需要很高的技术水平,但是你看到的爬电线杆的抄表的,都是低技术岗位。

    话说我们每天主要的工作就是写脚本,这也是在开发啊。
    twl007
        16
    twl007  
       2015-03-07 17:39:47 +08:00 via iPhone
    @echo1937 没办法 随着现在集群规模的扩大 以后肯定是自动化运维了 那大量的运维脚本…… 其实就是开发啊…… 只是方向不同而已…… 我会说我是觉得运维写代码少才入坑的么…… 结果现在…… 满满的泪……哎
    bellchu
        17
    bellchu  
       2015-03-07 18:16:05 +08:00 via iPhone
    请大家谈一谈自己的看法,关于行政这个岗位
    请大家谈一谈自己的看法,关于财务这个岗位
    请大家谈一谈自己的看法,关于销售这个岗位
    请大家谈一谈自己的看法,关于市场这个岗位
    请大家谈一谈自己的看法,关于XX这个岗位
    greatdk
        18
    greatdk  
       2015-03-07 18:27:35 +08:00
    WhiteBase
        19
    WhiteBase  
    OP
       2015-03-07 19:33:21 +08:00
    @twl007 嗯,确实运维转架构、自动化运维都是方向。对这个岗位知之甚少,所以需要有经验的人指点一二啊,看来这位前辈是有比较清晰的职业发展方向了,我现在就是在关口上,所以想要多了解,毕竟工作方向还是一件需要慎重的事。

    @TimLang 24h on call 这点比较怵,我是见到一个一位SA前辈长期失眠的,虽然据他说不是这个原因。年轻人确实应该拼搏,但是下班了还要随时待命的状态不是每个人都能够轻易接受的,这和好逸恶劳无关,就是要 work-life balance。

    @datocp 是自己喜欢的公司,但是岗位却和自己想象中偏差有些大,这两点就搞得很纠结。您说的对,无论在哪里,学习心态很重要。还有我尤其赞同您说的要跳出这个行业,有时候看看传统行业,人家存在了那么多年,最终还是养活了那么多人,必然还是有它的生机。

    @echo1937 您说的很有道理,的确都在往云计算方向上发展,还有运维地位低这一点,我也觉得,怎么说呢,这种鄙视链是在让人有点儿懊恼,有时候经常给涉世未深的人误导:比如C/C++的看不起Java,搞算法的看不起写业务逻辑的,测试的常常被当成“厕纸”。还在知乎上看到人开地图炮,说“程序员情商低,一群猴子”。虽说喜欢就好、自己做的开心就好,但是有时候就是不深入去做又怎么知道到底喜不喜欢呢?试错成本又高。就好像喜欢高中物理的人不一定真的喜欢大学物理,喜欢大学物理的人不一定喜欢物理研究。老实说,我很害怕那种感觉,就是突然有一天你发现你做的事情不过如此,甚至有时候很愤慨,听过一些工作一段时间的前辈感叹,“工作嘛,也就是养家糊口,做什么不是做”,真的和那些激情满满的创业者形象截然相反。
    046569
        20
    046569  
       2015-03-07 19:52:42 +08:00   1
    现在运维自动化程度越来越高,更多的时候趋向于开发.
    认为运维等于操作员,就如同说程序开发只需查API手册,你觉得这说法靠谱么?
    有时候我们不敢尝试更多,只是高估了试错成本.
    年轻,有很多种可能.
    WhiteBase
        21
    WhiteBase  
    OP
       2015-03-07 20:02:00 +08:00
    @046569 说得很在理,这话确实是给自己画地为牢了,还是要给自己一颗敢想敢做的心。这位前辈是做运维的吗?
    pfitseng
        22
    pfitseng  
       2015-03-07 20:26:42 +08:00 via iPhone
    @yangtuo t/175190 请程序员发挥下基本功试试
    yangtuo
        23
    yangtuo  
       2015-03-07 20:29:36 +08:00
    @pfitseng 你让我钻我就钻啊,你特么是老几?你知道老子一小时的技术支持费用是多少吗,说出来吓死你。
    pfitseng
        24
    pfitseng  
       2015-03-07 20:31:13 +08:00 via iPhone
    @yangtuo 写php的吧,傻逼
    yangtuo
        25
    yangtuo  
       2015-03-07 20:35:17 +08:00
    @pfitseng 操你妈写php的怎么了,老子会写的多了去了
    twl007
        26
    twl007  
       2015-03-07 20:46:03 +08:00 via iPhone
    @yangtuo 已Block
    twl007
        27
    twl007  
       2015-03-07 20:52:39 +08:00 via iPhone
    @WhiteBase 现在这个趋势…… 无论你自己怎么走最后都会走到自动化运维去…… 尤其在云上部署集群的 你可以看一下使用AWS开发的那些管理软件…… 最后其实也算是研发了 真心就是方向不同…… 还有不同的地方就是你要对系统配置非常熟悉才行 这个可能是跟程序最大的区别了吧…… 如果开发系统程序需要深入知道的是点 那你就是面了…… 渴望能某一点深度不如程序但是最后开发的东西要涵盖的东西就很多了…… 其实我觉得要是弄一个自动化运维系统专门承接各种公司的运维工作也不错啊……
    c0878
        28
    c0878  
       2015-03-07 20:56:45 +08:00
    对于Dev-ops这种岗位 我觉得开发出身的转型过去比运维出身的转型要容易
    纯运维以后会逐渐没落 但是运维开发,自动化运维以后会持续有强大的需求 是未来的方向 如果有机会可以勇敢去尝试 一人管理上千上万台服务器是很爽的
    对于24小时on call,作为一个负责任的运维是必须的,但是你半夜接到多少电话是和你能力挂钩的。强大的架构可以让运维夜夜安睡到天明
    pfitseng
        29
    pfitseng  
       2015-03-07 21:11:59 +08:00 via iPhone
    来回答一下楼主的问题:做甲方
    ChiangDi
        30
    ChiangDi  
       2015-03-07 21:23:54 +08:00
    不乐观啊,现在云服务越来越多,比如 Heroku 之类的,都自动化了,运维的需求越来越少了。
    twl007
        31
    twl007  
       2015-03-07 21:35:10 +08:00 via iPhone
    @ChiangDi 运维需求不会减少 只是会越来越集中 毕竟企业级别的运维需求不是光靠程序员就能解决的 毕竟云只是把运维的压力转移给了服务提供商 本身需求是不会变的 不过另一方面说就是运维的门槛高了…… 本来要去熟悉各种配置已经很难了现在还要能去写脚本 也是蛮拼的……
    WhiteBase
        32
    WhiteBase  
    OP
       2015-03-07 21:35:29 +08:00
    @twl007 嗯,看了您的回答,我算是逐渐明白运维的职业发展了,也破除一些误区了,多谢多谢!

    @c0878 哈哈,坊间传闻国内的某搜索从开发到上线堪称神速,搜索结果数据也很接近Google,于是有人推测,就是那个能拿到代码的归国了的前google运维工程师发挥了很大作用。这个传言侧面能证实有多爽。不过看到google机房的图片,的确是很震撼!关于运维架构的事也很有启发。

    @pfitseng 这个,最优解但是→_→也是无解啊
    wwek
        33
    wwek  
       2015-03-07 21:50:40 +08:00
    DevOps
    有谁比程序员更懂测试?
    有谁比程序员更懂部署?

    程序员别狭隘,别只会敲代码。网络,运维,测试还是的会的。
    twl007
        34
    twl007  
       2015-03-07 21:51:49 +08:00 via iPhone
    @WhiteBase 其实Facebook有个在北极圈的机房很赞啊…… 要是能去那就好了……

    不过运维岗位真心少 现在我还记得毕业的时候去某公司来招聘有运维岗去面试 然后技术部主任来了句是不是我们不来你就找不到工作了……凸^-^凸 不过反过来说运维也是蛮稳定的 而且年纪大了工作压力也不见得会变大…… 毕竟很多东西就算个人再叼也得要时间去熟悉吧……

    我搞这个是因为比较喜欢折腾系统…… 然后技能树点成这样出坑也难了…… 以后安心朝自动化运维发展吧…… 不过这几年很多基础架构的东西也在不断出新的 估计以后也可能跟程序一样不停熟悉新的东西?

    至于半夜打电话么…… 我觉得如果运维环境很成熟的话不会很多了额 自动化运维系统不是摆着看的 可以参考一下Instagram 那么少的人就在AWS上构建了一套自己的集群并维护的好好的 所以如果有个成熟的运维环境时间长了搞不定真成操作员了……
    046569
        35
    046569  
       2015-03-07 22:04:36 +08:00
    2013年入了运维的坑,至今乐在其中.
    111111111111
        36
    111111111111  
       2015-03-07 22:07:46 +08:00 via Android
    @twl007 同意,最近在搞postfix 搞得挺烦,总是做完以后发现还有很多没考虑到,又要配置
    111111111111
        37
    111111111111  
       2015-03-07 22:12:09 +08:00 via Android
    云计算补刀好痛……传统行业更是 ,网络服务包给云更省心省钱
    zent00
        38
    zent00  
       2015-03-07 22:32:55 +08:00
    感觉 v2ex 最近素质低劣的人越来越多了,都 Block 不过来。
    9999999999999999
        39
    9999999999999999  
       2015-03-07 22:38:40 +08:00
    @* block
    pfitseng
        40
    pfitseng  
       2015-03-07 22:38:42 +08:00 via iPhone
    @111111111111 云就是坑,以后都要从公有云逃出去的
    111111111111
        41
    111111111111  
       2015-03-07 22:39:59 +08:00 via Android
    @pfitseng 坑在哪里呢。还没发现唉
    wwek
        42
    wwek  
       2015-03-07 22:58:26 +08:00
    @zealic 不能同意更多~
    twl007
        43
    twl007  
       2015-03-07 23:31:29 +08:00 via iPhone
    @111111111111 会绑架用户…… 尤其当你所有的服务都构建在运上面的时候 IaaS还好 至少整套服务器的平台 架构你还在自己控制 但是那个价格……

    至于PaaS…… 真让你的业务在上面跑起来了想再迁移出来那真的是要费尽了…… 不是一般的费劲……

    还有就是敏感数据你也不会仍在云端吧……
    ETiV
        44
    ETiV  
       2015-03-07 23:48:14 +08:00   1
    我在一个游戏项目组做过运维, 远程管理服务器, 非虚拟机, 也非小霸王.
    由于机房有公司的人, 所以那些硬件我也没接触过.

    电话是 24小时待机的, 可能随时接到电话处理问题.
    当然我这人可能比较没心没肺, 干完活了接着睡, 睡眠质量也挺好的.

    服务器例行停机维护; 服务端 / 客户端更新部署...当然这些都是运维该做的.

    还有一些, 跟运营同事的互动:
    参与运营组的各种开会讨论
    每周一早晨上班, 从服务器上拉各种业务数据回来, 对上周进行总结和分析
    等等~~

    这边跟运营开完会, 还可以跟开发的同事互动, 学习.
    官网的活动页, 只要我们组美术提供设计图, 我也可以自己写出来, 部署上去.

    我觉得运维这个角色可以说是承上启下的.

    纯开发的同事可能不会知道游戏的这个功能点为什么要这么设计, 会带来多少收入. 他们只是按需求去做事情, 有的时候还会因为这个功能点麻烦, 还要讨价还价一番.

    纯运营的同事, 虽然没有鄙视的含义, 但估计代码都不会看得懂.

    所以在我看来, 运维这个岗位可以接触到很多东西, 当然你可能会觉得某些方面挺苦的.
    不过如果这是你第一份工作, 我建议你还是尝试一下.
    frankzeng
        45
    frankzeng  
       2015-03-08 00:06:22 +08:00
    运维这角色要看公司,如果你公司有上万台服务器,运维会相当重要,大公司运维都分了好多种,基础运维,网络运维,最后才是系统软件层面上的运维。就算是系统运维,也分为自动化开发,运维系统开发等。我以前的同事都会看代码改bug,修改代码紧急上线这些也是运维人员必备吧。
    WhiteBase
        46
    WhiteBase  
    OP
       2015-03-08 00:28:43 +08:00
    @ETiV 嗯,听您这么一描述又有了新的认识,多谢多谢!
    Bruta
        47
    Bruta  
       2015-03-08 00:52:04 +08:00   1
    难得遇到一个自己可以说两句的话题啊。
    2011年机缘巧合来了上海谋了一份美企的Opration Engineer的职位,三班倒,做三休三,刚开始的时候就是很多人认为的操作员的工作,鼠标点点,知道怎么上线跟新,怎么跟开发沟通。渐渐的开始学习Shell,Python,然后刚刚好公司将业务开始转型到Amazon AWS上,接触得越多越发现,传统的操作员的市场需求会越来越少了,于是更多的精力开始放在写Python脚本上,想办法如何利用AWS的API去完成老大交代的任务,并且让自己更多的偷懒。
    去年的时候,发现倒班倒不动了,就换了一家小的民企做应用运维。不需要倒班了,平常大部分时间都花在写写自动化脚本,做得也挺开心的。运维在公司内是一个很容易被边缘化的部门,如果逐渐被边缘化的话,在大家看来当然就会觉得运维的价值远低于开发。但是借用最近看过的一句话,‘优秀的运维已经在领导架构了’。
    那么,一个没有被边缘化的运维团队大概是什么样的呢?
    1. 应用运维,或者称之为业务运维,运维团队中最懂各自负责的产品线的人,直接接受开发,测试的需求,包括上线发布,回滚等等操作,并且精益求精,提高响应的质量,降低响应的时间。也是最必需最基础的运维。
    2. 系统运维,关注点在系统以及一些常用工具架构方面,一部分需求来自于研发,但是大部分时间是为了做好架构,方便业务运维更快的响应。
    3. 平台开发,也就是DevOps,随着公司业务线越来越多,业务运维中可以提取出来的重复操作集中到平台化处理,降低业务运维的压力。因为需要搭建的平台跟业务相关性很大,所以不太可能有现成的开源工具可以使用。如果团队精力足够的话,公司内部的一些工具也可以交给平台开发做。
    4. 数据运维,或者叫数据挖掘,这一部分想象力就很大了,能做到什么程度,就全看本事了。从最基本的报表,到最终的预测,这块儿要做好,太难了。
    5. 安全运维,这个就更精细化了。安全是互联网公司躲不掉的一个点。重要性也不言而喻了。

    所以说,现在还觉得运维是操作员的话,那就是拿上个世纪的眼光在看问题了啊。

    但是不得不提的现状是,大部分公司里面,薪水:开发高于运维。

    最后留一句忠告吧,如果选择做运维的话,一定要选一个运维没有被边缘化的公司。
    twl007
        48
    twl007  
       2015-03-08 03:47:08 +08:00
    @Bruta 主要是运维很多时候并没有明显价值的体现…… - - 不想开发 一个新的产品可以带来大量的利润 运维能带来什么? 很难感受到…… 一直平安无事觉得你不在干事 一出了问题就全是你的责任 = =
    ericFork
        49
    ericFork  
       2015-03-08 05:29:43 +08:00
    运维并不等于 OP,在国内互联网公司,运维这个词覆盖的实际岗位种类太多了
    MrGba2z
        50
    MrGba2z  
       2015-03-08 05:48:44 +08:00

    建议看这个视频

    如果不是高强度的岗位的话
    可以拿着工资
    在业余搞自己感兴趣的东西
    wolfdolf
        51
    wolfdolf  
       2015-03-08 07:35:21 +08:00
    @twl007 别扯了,靠这个证3w年薪都保不了吧? 具体可以问@Livid
    Livid
        52
    Livid  
    MOD
    PRO
       2015-03-08 07:36:50 +08:00 via iPhone
    @zent00 那个骂人的 ID 已经被禁用。
    efi
        53
    efi  
       2015-03-08 08:59:09 +08:00
    @yangtuo LOL
    晒W-2吧
    Actrace
        54
    Actrace  
       2015-03-08 09:54:45 +08:00
    @Bruta
    最近真是边缘化了。。。
    除了做完你说的那全部运维类型的工作,还得负责听boss吐槽抱怨修电脑补网络,最后被boss丢了一句:“你们部门算是公司里最闲的了,做这些事情时应该的,如果只需要管服务器的话我只要一个人就够了。”
    pfitsen9
        55
    pfitsen9  
       2015-03-08 10:14:06 +08:00 via iPhone
    @Livid 昨天一时冲动失言了,影响到大家对不起。那个账号签到了500多天了,对我来说也带有感情,能不能撤回禁言的决定?
    anubiskong
        56
    anubiskong  
       2015-03-08 10:14:41 +08:00
    我待过的公司, 运维都是干的擦屁股的活, 出问题是你的责任, 没出问题人家也没必要奖励你, 总之吃力不讨好. 你有这个能力, 何不去做点开发
    Felldeadbird
        57
    Felldeadbird  
       2015-03-08 10:48:27 +08:00
    @anubiskong 再补一点。现在中小的运维直接内部程序员担任。反正不出问题就行了。一些公司招运维,用完可能就炒了。
    yghack
        58
    yghack  
       2015-03-08 11:01:29 +08:00
    @anubiskong 无比赞同你得观点,我现在所在的一家公司,程序不给力,对接公司API不给力,都是运维去补洞子的,除了问题第一想的不是程序是不是出问题,想的是服务器是不是出错了。
    xderam
        59
    xderam  
       2015-03-08 11:06:11 +08:00
    尽量别去小公司.否则就会被当做IT或者桌面一样的用了...
    WhiteBase
        60
    WhiteBase  
    OP
       2015-03-08 11:06:46 +08:00 via iPhone
    @anubiskong 所以啊,现在真是纠结,这种做了不讨好,不做就全是责任的感觉真是太压抑了。


    @Felldeadbird 好吧,也太不厚道了吧。
    9hills
        61
    9hills  
       2015-03-08 11:09:24 +08:00   2
    我厂的运维更多的是应用运维,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
        62
    arachide  
       2015-03-08 11:23:42 +08:00
    分大中小

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

    以后后端不知是写php脚本和前端交互
    多指自动化运维脚本开发和写大数据bi分析算法
    现在的脚本程序员要不转行要不淘汰
    rentaro
        63
    rentaro  
       2015-03-08 11:32:41 +08:00
    "运维"这个词就有问题,涵盖了不少角色,被误解太深,改成平台开发工程师会不会好点,我知道的几位 linux 社区的视野明显不同,编程功底远超普通程序员。
    invite
        64
    invite  
       2015-03-08 11:48:17 +08:00
    别小看运维, 运维很多时候需要经验。

    而开发,说实话,如果上不去,一辈子码农,还没运维好。
    mN71eOOprFyMsnPx
        65
    mN71eOOprFyMsnPx  
       2015-03-08 11:53:11 +08:00   1
    工作8年,一直是运维 + C++开发,悄悄告诉你这样的组合很爽。
    我的经历体会就是纯粹的做开发的同事,思维好窄!
    twl007
        66
    twl007  
       2015-03-08 11:54:25 +08:00 via iPhone
    @wolfdolf 现在教授的一个毕业的学生靠着这个在Housyon找的10w刀的~ 信不信随你…… 反正真的就这么多
    twl007
        67
    twl007  
       2015-03-08 11:57:08 +08:00 via iPhone
    @wolfdolf Houston 打错……
    Admstor
        68
    Admstor  
       2015-03-08 11:57:23 +08:00   1
    看不过少开发人员早期弄些一键安装包搭起来的系统,一塌糊涂
    最后丢给运维擦屁股

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

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

    简而言之,运维是会随着公司成长越来越重要
    你觉得运维对你不重要,说明你们公司根本就没达到一个规模
    xderam
        69
    xderam  
       2015-03-08 12:08:17 +08:00
    前两个问题没太看懂.可能水平不太够.MC做的事情?索引? 或者是对业务场景了解的不太深..
    最后一个问题还是比较通用的...晚上好好算算..
    xderam
        70
    xderam  
       2015-03-08 12:08:59 +08:00
    @9hills 前两个问题没太看懂.可能水平不太够.MC做的事情?索引? 或者是对业务场景了解的不太深..
    最后一个问题还是比较通用的...晚上好好算算..sorry 刚刚没有at上.
    twl007
        71
    twl007  
       2015-03-08 12:13:17 +08:00 via iPhone
    @Admstor 擦了好多屁股的飘过……
    banri
        72
    banri  
       2015-03-08 12:17:41 +08:00
    经历+精力
    efi
        73
    efi  
       2015-03-08 12:27:14 +08:00
    @yangtuo 的新马甲是 @pfitsen9 。这是在模仿被你骂的这位 @ pfitseng 么?
    hdbean
        74
    hdbean  
       2015-03-08 12:27:52 +08:00
    已从运维转开发
    efi
        75
    efi  
       2015-03-08 12:28:23 +08:00
    Jeff Dean就是顶级运维。
    pfitsen9
        76
    pfitsen9  
       2015-03-08 12:32:48 +08:00 via iPhone
    @efi 什么意思,我的原账号是 @pfitseng ,被禁言了,早上不能登录了。那个yaotuo注册才几天,怎么可能签到500多天
    Monad
        77
    Monad  
       2015-03-08 13:34:54 +08:00
    @ETiV 要是开发同事不知道怎么设计甚至提出挑战,策划会摆出各种数据告诉这个开发为什么要这么做,这么做会带来稳定的活跃还是收入点,这一切都不需要策划和运维沟通讨论任何问题。
    所以至少在游戏的功能点设计上,开发比运维清楚。
    ETiV
        78
    ETiV  
       2015-03-08 14:50:13 +08:00
    @Monad 嗯. 你侧重的是 "话语权" 的问题上, 我说的是心态的问题.
    实际上我也没有表示出运维这个角色, 在研发环节上比运营/策划/程序员能有多少分量.

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

    另外, 我说的跟研发沟通是指技术上的沟通, 而非游戏运营, 或功能点策划.
    "数据库表结构是如何设计的" 这类问题. 毕竟里面牛逼的人还是有的, 多讨教讨教嘛
    nnfish
        79
    nnfish  
       2015-03-08 15:59:29 +08:00
    楼主担心“ 不做开发,做运维会不会把这路越走越窄”

    我的观点是:

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

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

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

    总结:
    条条大路通罗马,只要自己足够勤奋和努力 + 一个好的工作环境
    Monad
        80
    Monad  
       2015-03-08 16:47:53 +08:00 via iPhone
    @ETiV 那看来就是个体差异了 我们的开发在业余时间也基本不会登陆自己游戏看,运维就更少了。
    不过我觉得运维对于游戏的作用还是在于对机器和网络故障的跟踪,快速反馈和处理,真正具体到游戏业务的话反而不是一个运维该接触的。而至于游戏的架构则是开发确定下来的,运维当然可以提出各种建议,但是代码是开发写出来的,开发#理应#比运维更了解这些东西。
    不知道你的观点如何。
    ETiV
        81
    ETiV  
       2015-03-08 18:12:54 +08:00
    @Monad 对. 我也同意"运维应该在自己工作范围内更加深入的去学习".
    但是作为一个想要成长的更快的人来说, 多接触一些周围领域的事情也不算坏.

    而且我算是跟楼主一样, 曾经做过有着这一颗码农心的运维. (我还做过有着码农心的谱面Editor...)

    我有个朋友, 在国内游戏网站做运维主管.

    那哥们运维做了好些年, 真真儿资深运维...啥都会, 从线上软件环境调优, 到硬件防火墙, 程控电话交换机配置.

    刚入行的时候, 该苦逼一样苦逼: 工资不多, 经常各地机房的跑. 没出状况的时候, 上头觉得这些都是理应的事情; 等出了状况就...

    他现在的经济条件比以前好太多. 起码自己和老婆都有各自的车开.
    但是他不敢跳槽, 不敢换工作. 因为一来不会别的, 二来好像别的公司也不是很需要如此资深的运维, 或者开不出他理想的价格.

    以我看来, 他把自己眼光和想法, 太聚焦在一个点上了, 虽然扎的很深, 但人生道路可以说是越走越窄, 选择也越来越少.


    咱换个方向, 因为我主要想说的是 "心态" 问题, 而非谁更应该专注于"写代码", 和对一套软件项目的架构更有话语权.

    再讲另一个朋友, 大学的时候学的是生物制药.
    但这哥们对音乐很感兴趣, 毕业后去了音乐游戏公司.
    他在岗位上**应该**做的事情都是跟音乐相关的, 每天面对的也是钢琴键盘.
    做了几年之后, 跳槽出去自己创业了(真正的公司创始人, 而非合伙人什么的), 也是一个音乐游戏公司. 产品出来后还买到了马来西亚.

    所以你看, 生物制药的学生 -> 作曲家 -> 游戏公司老板.
    我敢说他这样的人在上学/上班的时候一定是非常"不务正业"的, 才能有如此大的跨越.
    icecream187
        82
    icecream187  
       2015-03-08 18:57:43 +08:00
    DevOps
    icecream187
        83
    icecream187  
       2015-03-08 18:58:27 +08:00
    我公司之前见过 C开发做起来运维比真正的运维还好。
    cmheia
        84
    cmheia  
       2015-03-08 19:11:22 +08:00
    前不久看到的,风险还是不小啊
    fstab
        85
    fstab  
       2015-03-08 19:20:05 +08:00
    @cmheia 当时看到了哈了下。。现在想想感觉离自己很近。
    ksupertu
        86
    ksupertu  
       2015-03-08 19:21:21 +08:00 via Android
    斯诺登就是运维啊,年薪20万美刀呢
    xxr3376
        87
    xxr3376  
       2015-03-08 19:27:47 +08:00
    @FifiLyu 能不能给举个例子呀,只做开发的具体在哪些场景下思维太局限呢?
    mN71eOOprFyMsnPx
        88
    mN71eOOprFyMsnPx  
       2015-03-08 20:17:49 +08:00
    @xxr3376
    要开发新功能时,刚描述完需求,就会说:“啊,这个不太可能完成。”;
    写代码时,什么方法简单就用什么方法,不会管部署后是否好维护,是否好更新;
    前后开发的功能经常是不同的风格,不会考虑用户使用的习惯或者用户的学习成本;
    最后一个同事被公司挖走,我接手项目代码,惨不忍睹。无输入参数验证,无代码重用,无注释(代码也不能自说明),无内存检查(C++项目,全是用C写代码),无容错,一个单CPP文件有几千行完全混乱的代码等等,前前后后重构了10多次,花费快2年,才最终算是对得起拿的我开发岗位的工资。


    PS 运维大概分几种:
    负责在机房“板砖的”,一般招聘时写的岗位是“网管”;
    负责网络设备管理的;
    负责系统级别的管理,比如管理Windows、Linux等等,也就是System Administrator,简称SA;
    其它;
    JayFang1993
        89
    JayFang1993  
       2015-03-08 20:30:53 +08:00 via Android
    服务器的基友
    Actrace
        90
    Actrace  
       2015-03-08 20:39:48 +08:00
    @anubiskong 好蛋疼,当我是开发的时候,出问题都是开发的问题。。。当我是运维的时候,出问题都是运维的问题。。
    xxr3376
        91
    xxr3376  
       2015-03-09 00:32:22 +08:00
    @FifiLyu 我觉得你这个描述的开发是。。不懂规范、不考虑可维护性、能力太渣吧= =,不过确实是需要注意的事。。
    zhengkai
        92
    zhengkai  
       2015-03-09 00:51:36 +08:00 via Android
    如果没到饿得吃不上饭,还是找一个你喜欢的工作把
    holinhot
        93
    holinhot  
       2015-03-09 01:03:25 +08:00
    运维不会写代码那都是菜鸟运维。什么自动监控 故障统计都要写一些适合自己的管理工具的啊
    mN71eOOprFyMsnPx
        94
    mN71eOOprFyMsnPx  
       2015-03-09 01:10:37 +08:00
    @xxr3376 不止一个。是N个都这样。
    liyaoxinchifan
        95
    liyaoxinchifan  
       2015-03-09 01:15:02 +08:00
    @yangtuo 你好像一条狗啊
    1  2  
    关于     帮助文档     自助推广系统     博客     API     FAQ     Solana     898 人在线   最高记录 6679       Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 199ms UTC 22:24 PVG 06:24 LAX 15:24 JFK 18:24
    Do have faith in what you're doing.
    ubao msn snddm index pchome yahoo rakuten mypaper meadowduck bidyahoo youbao zxmzxm asda bnvcg cvbfg dfscv mmhjk xxddc yybgb zznbn ccubao uaitu acv GXCV ET GDG YH FG BCVB FJFH CBRE CBC GDG ET54 WRWR RWER WREW WRWER RWER SDG EW SF DSFSF fbbs ubao fhd dfg ewr dg df ewwr ewwr et ruyut utut dfg fgd gdfgt etg dfgt dfgd ert4 gd fgg wr 235 wer3 we vsdf sdf gdf ert xcv sdf rwer hfd dfg cvb rwf afb dfh jgh bmn lgh rty gfds cxv xcv xcs vdas fdf fgd cv sdf tert sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf shasha9178 shasha9178 shasha9178 shasha9178 shasha9178 liflif2 liflif2 liflif2 liflif2 liflif2 liblib3 liblib3 liblib3 liblib3 liblib3 zhazha444 zhazha444 zhazha444 zhazha444 zhazha444 dende5 dende denden denden2 denden21 fenfen9 fenf619 fen619 fenfe9 fe619 sdf sdf sdf sdf sdf zhazh90 zhazh0 zhaa50 zha90 zh590 zho zhoz zhozh zhozho zhozho2 lislis lls95 lili95 lils5 liss9 sdf0ty987 sdft876 sdft9876 sdf09876 sd0t9876 sdf0ty98 sdf0976 sdf0ty986 sdf0ty96 sdf0t76 sdf0876 df0ty98 sf0t876 sd0ty76 sdy76 sdf76 sdf0t76 sdf0ty9 sdf0ty98 sdf0ty987 sdf0ty98 sdf6676 sdf876 sd876 sd876 sdf6 sdf6 sdf9876 sdf0t sdf06 sdf0ty9776 sdf0ty9776 sdf0ty76 sdf8876 sdf0t sd6 sdf06 s688876 sd688 sdf86