elasticsearch 自动停止_自动化运维时代，运维失去价值了吗？

最近一直在思考，大家又谈到运维苦逼，没有成就感的事情，也促使我更加的想表达一下运维价值方面的东西。

首先，之前所讲的专题是在运维自动化专场，后来一些交流下来，我们共同的感觉是，听众们都特别的关注运维自动化，恰恰说明了我们现在运维的现状是：有太多的公司还没有自动化或者自动化程度很低，还没有找到明确的自动化的方向和思路，所以大家才会有这样的需求。回想起会后，也有很多的同学联系到我，说没想到运维还可以做这么多的事情，能不能让我给点建议，运维应该怎么做起等等，也印证了这一点。那问题到底出在哪儿了？

这里先不谈运维自动化的问题，想先表达两个观点：

• 运维不仅仅是自动化，还有很多方向值得我们去发力
• 运维，技术不是问题，重要得是思维上的转变

运维不仅仅是自动化，还有很多方向值得我们去发力

前两天在运维群里，针对运维价值应该怎么呈现，我们的机会在哪里，表达了一下自己的观点，大致意思是：一个公司对于开发这个角色的诉求，永远是怎么能更多更快的把业务需求和功能实现，并尽快发布到线上，从而让业务能够实现快速的流量引入和变现。如果一个公司的开发都跑去关注怎么提升资源分配的效率，怎么提升发布效率、怎么提升线上稳定性、安全，还要额外去考虑下成本问题，这本身就已经脱离了一个公司对开发的诉求。那这个时候暴露出来的，效率、稳定、安全、成本等等问题，谁来解决？

刚才已经提到，开发同学应该不是这些问题解决的主体，那一个技术团队，还有哪些角色适合？测试 or 项目经理 or运维 or XXX角色，貌似看来看去只有运维最合适，因为运维离线上业务最近，对线上的情况是最熟悉的，其他任何一个角色都很难从端到端的视角是看待这些问题，即使看到了，也很难能够有效（关键是很难有精力）的落地。所以这个时候，我觉得这些问题的解决就是运维同学的机会，而不要把他当成负担。

从技术团队和老板的角度来讲，对开发就是期望尽量多尽量快的完成需求开发，而对运维，可能很难提出明确的期望和要求，但并不意味着没有。那到底是什么呢？实际就是上面（效率、稳定、成本、安全和体验）这些隐性的期望，往往可能没有很显性地表达出来，运维自己又不能很好的领悟到这些事情的重要性时，一旦出现问题或线上故障，老板发现我们没有很好的达到以上期望，一腔的怒火就很容易就发泄到运维同学这里了。再进而，运维就越发的感觉到自己是背锅侠，越来越没有成就感。

所以，正着看，这些事情运维来做最合适，反着看，这些就是老板对我们的期望啊。正反我们都不跑不掉，那就不如主动做好。

之前朋友圈转的文章《不做伪工作者》，文章最主要表达的一个观点就是：要做对公司和业务最有价值的事情。运维确实做了很多事情（忙成狗），应急处理了很多线上故障（操着卖白粉的心），重大的变更必须放到凌晨操作（起的比鸡早，睡得比猪晚），真的是非常非常辛苦，但是这些事情真正创造了多少价值呢？可能这就需要我们好好思考一下了，这里我并不是否定我们运维在做的事情，这些事情说没法避免，肯定是要有人来做，由运维做也是应该的，但是我们千千万万不要陷在这些事情里面，自我感觉良好，自我认为做了很多苦劳的事情，就把这种状态当做常态了，如果是这个思路就是我们的问题了。我们得要寻求改变，往往这个改变的过程和结果，就是价值呈现的时候了。

通过以上可以看到，自动化只是一个技术手段而已，重要的是我们得要找到方向。下面是我总结的效率、稳定、安全、成本和体验的一些事情，这些跟GOPS上很多专题都相关，也说明运维可以有很多的方向去发展，期望对大家有用。

效率

这块跟日常的运维例行工作紧密相关，如资源分配&回收、域名配置、VIP配置、持续集成&发布、应用部署、应用扩容&缩容等，这块是运维最基础的工作，通常提到的运维自动化，大多是集中在这些工作上，因为这些工作偏日常和重复，目前业界的自动化的解决方案也非常完善了，所以可以优先把这些问题解决掉，目标就是解放运维的生产力，提升运维效率，降低人为失误，让运维的同学可以有更多的精力去做更有价值的事情。

稳定（质量）

让业务运行更加稳定，监控、全链路、强弱依赖、限流降级、容量评估、预案平台等，这块需要有相对比较独立和专业的监控和稳定性平台来支持，目标是最大程度的保障系统的稳定和运行质量，即使出现问题，也能够快速发现、快速响应、快速（自动）恢复。

安全

安全是与运维同等级别的一块专业领域，但同时又是跟运维紧密相关的，运维同样要关注安全，因为安全出现导致的问题，往往也会给运维带来沉重地防护和修复成本。我们经常提到的，各类主机安全、DB安全、Web安全、应用安全等等，与此相关的还有漏洞、DDos、CC等关键词。

体验

这里提到的体验，指的是终端用户的访问体验，非功能或产品使用体验，对于运维来说就是要关注访问速度。作为开发的同学来讲，可能更多的注意力会放在自己负责的代码以及该部分的性能问题，不会关注到端到端全流程的性能和体验。但是运维可以站在全局的角度来审视和治理整个端到端全链路的性能情况，并给出对应的性能优化建议。

成本

成本问题，也就是技术ROI（投入产出比）的问题，当系统规模和体量变大之后，掌控在运维手中的各类资源，将占整个研发团队支出的大头。如果没有很好的成本控制意识和策略，资源体量将会持续增大，甚至是翻倍或指数级的增长，对于公司成本会是非常大的负担和压力。

现在对运维来说技术不是问题，重要的是思路上的转变

现在各种业务跟中开源工具，比如自动化的puppet、ansible、chef等，监控有nagios、zabbix、cacti等，虚拟化有kvm，openstack，以及等等各种开源技术，各类商业的软件也同样百花齐放，可供选择的余地非常大。

所以，我觉得运维在技术上不是障碍。即使你觉得以上工具不好使，可以参选我们团队自己研发的ETL调度工具taskctl

关于taskctl

是一款功能全面的作业自动化调度技术管理工具。通过它可以快速将这些作业组织起来，并进行有效的管理以及各种参数化运行控制。在业界，普遍将这种技术称为作业调度，其技术本质是作业运行管理的自动化控制。

基于成都塔斯克旗下产品taskctl部署面向于个人、企业主和独立数据应用开发商提供的一个一站式大数据工具平台和社区。基础套餐永久免费！透过taskctl，个人和企业无需过多关注大数据底层存储和计算引擎的复杂的安装、繁琐的配置和日常运维，即可将自有的多来源业务系统数据进行集成和开发，形成数据资产，并赋能于自有作业场景，在云端轻松构建自有数据中台。

taskctl调度功能如下：

• 完成20多种数据源的适配调度：Mysql、Oracle、Hive、HBase、Redis、MongoDB、ODPS、Postgresql、ElasticSearch、WebService、GBase等；
• 模块化和可插拔的插件机制：屏蔽各种应用平台技术差异，适配统一的执行、停止及状态日志查询访问接口
• 支持可视化工作流配置：支持图形拖拽、自动化最小交叉排版，清楚地展示了作业节点之间的串并关系；不同类型作业图标自定义、正执行作业节点快速定位；
• 支持任务告警：邮件，短信，微信，钉钉等多渠道订阅，平台消息，流程消息、作业消息多层次推送。
• 人工干预多样化：正常调度，自由调度，虚拟调度。强制中断、强制通过、禁用通过、预设断点、忽略条件等；
• 支持作业优先级配置：平台级、流程级和作业级并行控制、资源权重设置。动态设置作业优先级置顶等操作。
• 支持工作流与工作流之间组装：支持各种层级的调度元信息架构组织，如：工程à工作流（可嵌套）à模块（可嵌套）à作业
• 支持工作流测试运行：支持流程开发完整体系，如编码à编译à调试à 版本发布à运行一整套完整的生命周期管理。
• 出错任务快速定位：提供了“正执行、异常”等状态的作业节点自动跟踪定位功能。

同类型开源对比：

总结

Apache Oozie 是一个重量级的任务调度系统，功能全面，但是部署及配置会比较麻烦，从 crontab 到 Oozie 上手会有一定难度。Azkaban 是介于 oozie 和 Crontab 之间的工具，但是安全性上不如 Oozie，同时如果出现失败情况，Azkaban会丢失所有的工作流，Oozie则可以继续运行。taskctl相较于以上两种工具而言，解决了配置及部署复杂的问题，易于扩展的同时，也在工作流中有了更多方便开发及运维的其他功能。

当然taskctl不仅仅是一个功能全面的工作流调度工具，作为一个一站式大数据平台，它同时涵盖以下功能，无论是简单的 ETL 工作，还是复杂的数据中台构建工作，使用taskctl都可以完成。基础版永久免费！无论遇到什么问题都能找客服解决。。。