在运维自动化群中，有一天我抛出了几个问题，引发了大家的热烈讨论，可以看出，很多人都有相似的痛点，很多路可能我们都在走过。我们来简单看一下。

问题1：

1.你觉得运维自动化平台从公司层面来推，和从部门自发做起，各有什么利弊？

    同学1：

从部门 发起 先做出一个demo 然后在后续争取公司的支持  可以自己慢慢做

    同学2：

 一个是运维团队并非所有人都重视自动化、思维无法转变  第二个 如果非运维出身，或者不了解运维 大leader并不一定都会重视

    同学3：

个人觉得自动化搞好，首先运维团队自身得有思维转变，有意识将传统的运维操作逐渐转移到运维系统；其次是在逐渐小范围扩展到开发团队，比如sql审核 实实在在带来便利和提高效率  也是一个灰度过程

    同学4：

可以抓痛点，单点突破，小范围试点。

问题2：

运维自动化使用Python还是Java要好一些？ 

    同学1：

python好用，但是要懂java，因为开发java多，尤其是问题调查方面

    同学2：

选择语言的关键在开发运维系统的团队整体技术栈，大黄易大多也是java

    同学3：

现在感觉好多都开始搞go了，实在跟不上

    同学4：

如果运维人员来开发，python或者go更合适，简单容易上手。如果是开发人员，另说，看开发人员熟悉的技能

    同学5：

Python   成本低，入门易，贴合度高

    同学6：

python,java各有秋千,不同角度和立场观点不一样，语言之争不讨论，应用开发选择就java吧，招聘容易点

问题3：

微服务架构对于目前的运维来说落地情况如何  

    同学1：

感觉做微服务对运维很大的一个好处是不用过于担心业务陡增，系统宕机，也不用担心某部分故障导致系统整体故障，还有，部署、发布多了，到轻松了

    同学2：

我在福州和深圳见过专门搞微服务的公司，还可以，但是投入有点小大。

    同学3：

微服务架构在业务层面应用较多，运维有待改进

    同学4：

关于微服务，个人觉得只要参考思想，形成一个个独立模块就好了，没必要搞什么服务发展，服务注册等等之类东西

    同学5：

传统IT架构、现有业务系统改造，自有庞大开发团队的公司可以考虑，尤其是IT企业，其他行业如果之前便采购一堆应用软件的公司不适用微服务，但对未来想规划开发团队，自研发很多应用项目则适用。

    同学6：

运维的顶层设计到目前主止，一般的大中型企业都旨在解决现实运维问题，架构基本稳定，花那么大代价微服务化，阶段和时间节点大部分企业都还没有到，但是像阿里云那样的绝对例外

业务系统就完全不一样了，变化快，发布周期短，业务细部功能高度自治，外部调用勾连紧密

    同学7：

应用的微服务部署对运维提出来更高的要求

    同学8：

微服务的很多程序，我们上线部署，也麻烦，如果调用链长，又没跟踪监控，就尴尬了

问题4：

大家了解的行业里的运维平台从上向下推进的成功率如何？ 

    同学1：

由上推下，领导cto认可，就会较容易，但是不能影响开发的项目进度和产品正常上线，否则肯定他们先行

    同学2：

赞同楼上, 如果这个需求上升到领导或公司层面那至少你做的平台确实是解决了实际问题带来了可观的价值, 不管是从人力还是物力上

    同学3：

说白了，运维平台，除了大公司，小公司只能一个部门自己先玩，就像，小河沟，以前都是绕一绕就过去了，你觉得造个桥方便，你只能自己造，同路的搭个便，找领导要钱去造难。除非，绕行十分困难

    同学4：

运维平台从上向下推进的成功率不算高，有见过，公司用Tivoli，下面都在玩Zabbix。当然这里的成功率要分阶段、分组织文化来看，通常一开始还不错，随着解决现实问题的能力下降，他的生命力就在走下坡路

    同学5：

自上而下的推进即时强推上去，实用性也欠佳，需要特殊模块带动，提供很好的工作方便性进行引导。

问题5：

一个大而全的系统（投入人员多一些）和一个快速迭代的系统，大家觉得哪个更容易成功？

    同学1：

个人推崇快速迭代。大而全，时间久，变数大

    同学2：

有领导支持当然好了，前提还要看执行者质量；开发的系统如果大范围使用，最重要的就是稳定，不能出幺蛾子 

    同学3：

千万别大而全, 这东西没有一个整体的思路或是规划, 后面自己都会放弃了

    同学4：

快速迭代吧，以我跟一些拍板的打交道的套路，没有直接效益东西，除非你找一个满嘴跑火车的人去沟通，要么就是确实带来整体的效益或者便利，不然出了门他都不记得这个事了

    同学5：

每个人关注点都不一样, 你可能关注功能的实现, 领导可能关注带来的便利, 总监可能关注成本的节省～ 要让这么多人认同其实还是不容易的～ 小范围试运行逐步迭代合并需求还是不错的～

    同学6：

快速迭代，快速迭代的需求源泉都是来自需求，来自生产一线，大而全的系统对不起，第一个通常是Demo

    同学7：

不好说，大而全就块头，笨，快速迭代则难，如微服务.

问题6：

前后端技术是否需要分离，比如运维不需要关注前端，不需要写前端页面？

    同学1：

如果运维自动化平台的前端的话，一般还是运维自己写吧，前端工程师最多也是建议，因为产品开发迭代的前端工作也不少～～

    同学2：

我觉得沟通成本太大了

    同学3：

这个平台开发肯定不能依赖开发，开发自己事情多的要死，根本顾不上

    同学4：

需要，运维人员最好忽略前端，通常运维想出来的前端都不靠谱，前端是个专业活

    同学5：

前后端需分工也需沟通，计划应用的时候，有基础架构、服务器的人参与建议

----------------------------------------------------------------

    当然上面的回答仅供参考，我也没有刻意去放大某些答案的结果。对于不同的企业，不同的阶段，自有不同的实践路线。

    在这个基础上，我想说的是主动学习和被动学习的事情，我在上一期的运维自动化分享群中，上半个月我还算盯的比较紧，安排计划，不断提醒同学分享，下半个月刻意没有去维护群，想看看群到底发展成什么样子。结果不出所料，大家显然走入了随机学习的阶段，这样的状态显然是和自己的预期有很大偏差的。

    在这段时间里，我们在紧锣密鼓的做一些事情，有运维开发的也有支持其他业务的内容，做了很多事情的时候，发现还是有很多的磨合之处。虽然有很多的不满意之处，但是慢慢的我看到了平台的雏形，也看到了一些业务场景能够落地了，所以这不是一个demo了，然后后续引入了一些接口化的服务，看起来平台的调用关系更松耦合了，这些都是值得高兴的点。

    本期的运维自动化分享会继续，还是需要大家的全力支持，扫下面的二维码来入群，入群的三个问题还是不变：

    1.你是否愿意分享工作中的经验

    2.你是否愿意做轮值群主

    3.你是否能在一个月内分享一次

每个问题1分，如果大于等于2分，那么欢迎入群。