碰到这种运维人员该怎么办

[VeryEase]

公司的运维人员， 从别的公司挖的，本身非开发人员，但是产品解决方案,技术选型都会让他参与会议，涉及到服务部署和网络资源分配都会看他的建议。 他可能比较熟悉 apache 家族的东西， 推崇用 apache 家族的开源项目解决所有问题，经常说按照他的部署方案，都不用 JAVA,C++开发人员写什么代码了...... ，而且 CTO 是产品经理出身，对技术细节也不了解， 觉得能缩短产品开发周期是好事，结果挖了一个又一个的大坑....。 不清楚运维人员具体的工作职责，这是否正常？

[lichao]

CTO 不应该是最懂技术的吗？

[k9982874]

CTO 是产品经理出身？逗我呢

[loading]

和老板说，拉他到你的团队，这样你就是他上级，然后把他炒了。

[VeryEase]

@lichao
@k9982874

CTO 不懂技术，这真是一言难尽， 内幕很黑暗， 公司就像个小社会，总有些斗争。 现在大家都有点郁闷。

[izoabr]

CTO 可以不懂技术细节（毕竟技术日新月异），但应该懂技术选型和方案规划，还有架构，当然最重要的是协调能力和沟通能力。最后终极的是业务能力（对业务的理解和对业务给出的解决方案）。还要考虑 TCO （总拥有成本、维护成本）。
所以 CTO 是一个很综合的产物，不是什么人都能干的，技术人员有部分甚至大部分都存在一个问题就是技术思维， CTO 就不能有这种思维，不能只从技术层面考虑问题，也不能不考虑技术问题， CTO 就是个桥梁，就是个中间件；还有就是技术（比如开发人员）就是要精专的，难免会一根筋，这是正常的，但是 CTO 就不能这样，如果 CTO 一根筋了，就容易钻牛角尖，团队和产品就容易出问题。

哦，说运维呢·····不好意思
运维，提意见很好啊，很棒，有些主管偏向也是可以理解的，只是需要一个更棒的人，从大局角度去说服他，去反驳他，最后拍板选择一个合适的方案出来。

[izoabr]

CTO 可以不懂技术细节（毕竟技术日新月异），但应该懂技术选型和方案规划，还有架构，当然最重要的是协调能力和沟通能力。最后终极的是业务能力（对业务的理解和对业务给出的解决方案）。还要考虑 TCO （总拥有成本、维护成本）。
所以 CTO 是一个很综合的产物，不是什么人都能干的，技术人员有部分甚至大部分都存在一个问题就是技术思维， CTO 就不能有这种思维，不能只从技术层面考虑问题，也不能不考虑技术问题， CTO 就是个桥梁，就是个中间件；还有就是技术（比如开发人员）就是要精专的，难免会一根筋，这是正常的，但是 CTO 就不能这样，如果 CTO 一根筋了，就容易钻牛角尖，团队和产品就容易出问题。

哦，说运维呢·····不好意思
运维，提意见很好啊，很棒，有些 [ [ [ [ [主管 /主观] ] ] ] ] 偏向也是可以理解的，只是需要一个更棒的人，从大局角度去说服他，去反驳他，最后拍板选择一个合适的方案出来。

[echo1937]

运维人员参与 产品解决方案，技术选型挺正常的.

出问题也挺正常的，只要责任明晰，哪个环节出问题打谁的板子呀。

[izoabr]

@echo1937 对的，不过这种会议会开得想革委会的会议那样。
发挥各自所能去提意见和建议是很好地事情，但主持会议和做协调决定的人特别重要。

所以说，兵怂怂一个，将怂怂一窝。

[9hills]

正常。

就好像说 rd 写代码正常，不能因为写的代码有 bug 就说写代码不正常了。。

[echo1937]

@izoabr

IT 建设不规范的时候， A 环节出问题，就会需要其他环节的人去补位，导致其他人跟着遭殃、跟着加班，搞得怨声载道。

这个时候就需要 CTO 来领导架构优化，明确职责分工，如果你们的 CTO 不懂这些，没关系，多扯皮，多撂挑子，迟早有人会受不了出来干这个事。

我们管这个问题叫“男生宿舍困境悖论”，祝撕逼愉快。

[izoabr]

@echo1937 嗯，支持。
不过还有一个现象，就像那句，铁打的营盘流水的兵。最初技术部门成立的时候，第一任 CTO 就已经决定了这个技术部门的风格和作风。 CTO 天天忙到咳血，谁不主动自觉完成自己任务再回家，等这个 CTO 咳血死了，殉职了，再换 CTO ，那这个作风应该是会被延续下去的。因为大部分人都已经养成了这个习惯和思维，新人是会被同化的。

至于前期不规范，每个团队都会有这个过程，但是格局一定要有，就像我们现在的网站就几万 PV ，那我们的架构规划也应该考虑到日后上亿的 PV 的情况，我们要提前去考虑将来要过渡到那个架构怎么能更顺滑，有经验的架构师就知道怎么做伸缩预留，就知道用虚拟化之类的手段去提前布局对吧？所以讨论环节其实 CTO 就可以把架构定得更高，预留更多空间，以免扯皮。

哈哈，他们这也够逗的， CTO 不拿事，研发和运维扯皮，还没个人能断案···好惨

[radio777]

CTO 是产品经理出身？人人都能当 CTO 了？

[unixbeta]

楼主典型的看不起运维吧，以为自己写代码的就牛逼了

[tinyproxy]

这是管理问题，不要甩锅给运维。。。

[VeryEase]

@unixbeta

.... 你想多了。不要随便上纲上线。

[VeryEase]

现在还没到甩锅的地步，大家都在积极填坑。毕竟产品马上上线了， 延误了时间，不是一个人倒霉，大家都有这个觉悟。 CTO 是新上任，第一次在公司主导产品开发， 想尽快完成产品第一版给大家看成绩的心态也可以理解。


楼上有人说是管理问题，是说到点上了。 不过这个问题估计不是一时半会可以改善....

[BSD]

既然都不用写什么代码，那就让他搭个测试环境折腾呗，折腾出来再说。。。。

[tinyproxy]

@VeryEase easy ，没上纲上线。同在创业公司，以前是研发，目前补位运维。看你描述，你们目前团队氛围还好，心还在一起就没啥大问题，但问题还是需要解决的。

[mongodb]

我觉得楼主心态挺好~ 知道有坑，但也没过多的抱怨，而是积极试图解决问题。

我觉得也别着急，技术方案不是死的，尤其你们第一版都没出来，可以说，什么都是问题，唯独技术选型不会是问题。定好一个就开始往下做，等以后在合适的时候引入合适的能帮你们梳理架构和技术栈的人，通常就不会在技术这条路上走死掉。

[yangqi]

楼主换个角度想想，如果你是 CTO 的话你能保证你们公司开发人员写的代码就不会有坑么？如果没有把握的话，这个方案可以缩短开发周期， CTO 刚上任当然想要早点出活，选目前这个方案也是很正常的。

不管怎么说也怪不到运维身上吧

[julyclyde]

从 CTO 的水平来看，你们公司整体是不行啊
我倒是建议该运维快跳槽离坑