运维的本质到底是什么？
那么运维的本质到底是什么呢？我觉得是服务，是服务于业务，因为运维是用技术解决业务问题，运维的价值要依托于业务才能体现。
运维不是因为技术高深，或者管理了几万台服务器而很牛逼，也不是能玩转很多开源工具而很牛逼，这都不是运维的关键。
观点：对于运维来说，服务第一，技术第二。运维技术再牛，如果不能服务于业务，帮助业务取得成功，那价值也是有限的。那么怎样服务业务呢？总结四点：
1.贴近业务：就是我们一定要与业务走得比较近，保持信息的畅通。
2.理解业务： 要知道业务目标是什么，用户群是什么，商业模式是什么样的。之前我见过很多运维，甚至在公司做了半年、一年，还不知道所运维的业务的商业模式是什么，这样的话，我们怎么能有针对性地提供服务，去帮助业务成功呢？ 理解业务还意味着要站在业务运营的角度思考问题，而不仅仅站在运维的角度思考。
3.挖掘需求背后的价值：我们经常会收到运营人员提出的需求，在理解业务的基础上，我们要挖掘这些业务需求背后的价值，比如说运营人员让发一个版本，做为运维，我们是不是把这个版本发布完就OK了呢？
肯定是不够的，我们还要去看业务发这个版本的目的是什么？可能是为了拉新用户，也有可能是做个活动去拉收入，或者是修复bug。
每一个版本的目的不一样，运维所做的事情是可以不同的。比如这个版本是拉新用户，我们把版本发布完以后，还可以采集更多的数据，去帮助运营人员分析，看是不是达到了拉新用户的目的。或者协助运营人员分析，这个版本的用户体验对于拉新用户是不是有瓶颈。这都是运维可做的事情，也是业务运营很需要的事情。
4.扩展服务价值：着眼于业务和服务，我们可以不断挖掘到新的价值点，扩展运维服务的价值。
当然了，这里绝不是说技术不重要，优秀的运维服务需要强大的技术来支持。举个例子，你想协助运营人员做用户体验的分析，这需要较强的技术能力来支撑。因为像上述的版本数据分析对实时性的要求很高，如果你没有及时分析出来，错过了运营时机可能就来不及调整了。
可以说，业务视角和服务意识决定了运维服务可以拓展到哪里，而技术能力则决定了这些服务最终可以实现多少。
一、运维的工作有哪些？
1.基础设施，包括网络、服务器、操作系统等工作；
2.环境管理，包括开发环境、测试环境、生产环境等；
3.部署，将应用或系统部署至不同环境；
4.监控，对基础设施、应用或系统进行监控；
5.告警响应，对告警通知的响应及处理；
6.性能优化，对系统及相关组件如Nginx、Java、PHP、DB或网络等的性能进行优化；
7.系统高可用，对应用系统中的单点进行高可用升级；
8.SLA保障，保证业务系统的可用性，可根据SLA实现自动扩缩容；
以上工作是根据运维管理框架进行提取，包含但并不限于以上几方面。
二、运维自动化
运维自动化可以实现的几个主要方面：
1.服务器上架自动化
新服务器或虚拟机从创建到交付到不同环境，需要进行一系列的定制，如cpu、内存、磁盘、ip地址、内核参数优化、时间同步、ssh加固、防火墙、各种客户端安装；当然这还不够，若运维平台集成了cmdb、跳板机、zabbix等，服务器上架还需要注册到cmdb及跳板机、zabbix等管理工具；如还有其他工具也需要进行集成。
总之，服务器上架自动化的最终目标是环境优化、安全可用、注册到一切管理工具。
2.环境定义自动化
环境自定义分两种情况：
（1）中小公司，测试环境包含所有的系统，即系统间是不隔离的，数据库中包含各种系统对应的库；
（2）大公司，每套系统需要单独一套隔离的测试环境，各系统间不能互相访问；
对于环境定义的自动化比较适用于第二种情况，需要对需求部门快速创建资源。
总之环境定义自动化的主要原则无论是哪种情况，都要进行不同程度的隔离，减少环境连错导致的问题。排查环境问题是运维比较恶心的一个问题。
3.部署自动化
部署自动化的过程是不断进化的，大体分为：脚本>批量ssh>自动化工具>容器，从每个过程来看部署自动化已经有批量操作>可用性>易用性>效率不断转变。部署自动化现在解决的不仅仅是部署本身了，还包括怎么才能更快，更容易屏蔽底层的不同。
注意：此处联想到《DevOps》思维导图中关于自动化中的提高速度，即自动化初步完成，还需要进行速度方面的优化。
另部署自动化完成后，需要和监控进行联动，即系统的可用性监控、性能监控等需要自动添加到监控系统。
4.监控自动化
从《系统监控体系》中我们知道监控对象分为从多个维度，每个维度可能用到的工具不一样，即监控自动化可能需要对接不同的工具。如：
（1）自动添加可用性监控，如端口、url监控等
（2）自动添加日志状态监控，如status、error等
当然监控自动化不仅仅只针对监控，还要兼顾到故障恢复的自动化，即故障自愈。
5.版本发布自动化
在服务器规模不大的情况下，版本发布要考虑摘节点、屏蔽告警等，需要和nginx、监控进行联动。如：
（1）nginx实现平滑摘节点
（2）调用api实现监控项的禁用及启动
五、运维自动化的几个阶段
站得高，看得远。无论我们正在做哪个方面的自动化，从更高的层次了解运维自动化的各个阶段，对我们更有益处：
1.操作自动化
这个层次的特征是把一系列的手工执行的操作，用脚本或工具串联，在一定程度上解决了运维手动执行的问题。但是不同的场景需要不断调整脚本或工具，反而增大了出错概率。
2.场景自动化
这个层次的特征是工具会根据外部环境判断如何运行，而这些判断条件是运维事先定义好的。此层次的运维系统需要各类环境数据来作为判断条件，同时还要能够变化操作行为。
另，此层次的运维系统需要跟很多第三方系统对接（cmdb、网管系统）。
3.智能化
此层次的运维系统具备数据核心（大数据存储，所有运营中的数据都会按关联关系集中存储），具备根据数据自己分析和判断、并自我决策和执行的能力。
在此层次，运维的主要工作是为系统增添分析策略、运营和维护此智能运维系统，以及在系统执行的关键节点上介入做人工判断。
六、怎样做运维自动化
在我们思考怎么做运维自动化之前，我们需要意识到“企业的架构不是设计出来的，是演变而来的”。因此我们可以借助这个作为指导思想。
1.先解决痛点
日常工作中，对常见问题进行分类和梳理，能做成工具的就工具化，能程序化操作的，就避免人为干预。
至于是否基于cmdb，反而不太重要，特别是如果业务系统并没有那么大，服务器的变动也没那么频繁的话。
2.选择正确的阶段
运维自动化一般沿袭这样的阶段：手动支撑 => 线上标准规范化 => 运维工具化 => 平台自助化/自动化。选择适合自己当前业务发展阶段的运维自动化方式，不要一口吃成胖子。
另外，对于大中型运维自动化平台而言， CMDB和配置系统依然不可或缺。
CMDB即配置管理数据库，一般用于统一管理IT数据、服务器数据资产等。CMDB数据的准确性和权威性，关系到运维自动化是否走在正确的路上。
七、总结
1.运维自动化
在以上自动化过程中，在不同的自动化阶段需要对接不同的第三方系统，因此可以看出一条统一的ESB（企业系统总线）来实现对系统的接口对接是多么重要。但是也并不是没有ESB就不好，不同阶段解决的痛点不一样，只有适合业务发展的阶段的运维自动化才是最好的。
2.运维管理
文章开头说运维管理主要目标是标准化/规范化，自动化，可视化/web化，从切身体验来看运维管理的目标也是随着运维自动化阶段的不同而变化的。
例如现在公司已经初步做到场景自动化及智能化，虽然还不深入，在一定程度上我的运维工作也已经解放了80%左右，已经给我释放了大部分时间，我也在想运维管理是否应该步入下一个阶段：运维服务化？
理由：
（1）运维自动化的价值在于，将运维从繁琐的、例行、容易发生人为事故的工作中脱离出来，做更有价值的业务运维和服务运维。
所以，从这个角度来看，运维自动化既不是起点，也不是终点。运维自动化不是万能的，我们需要看清楚它的位置。
（2）运维的本质到底是服务，是服务于业务，因为运维是用技术解决业务问题，运维的价值要依托于业务才能体现。运维不是因为技术高深，或者管理了几万台服务器而很牛逼，也不是能玩转很多开源工具而很牛逼，这都不是运维的关键。对于运维来说，服务第一，技术第二。运维技术再牛，如果不能服务于业务，帮助业务取得成功，那价值也是有限的。
运维自动化之殇
运维自动化是我们的必经之路，那么，一定就是解决所有问题的灵丹妙药么？可能不尽然哦。潜在问题包括如下：
1）忽略权限和基线
运维自动化平台通常由DevOps开发（例如Python + Shell），更多的是以实现功能为主，可能对账号权限或服务器操作权限，未做特殊限制，这样问题就来了，例如：
是否针对运维自动化平台的服务器账号做了特殊限制，使得这个账号只能操作指定目录，只能重启Nginx、不能重启PHP？
是否做了超限检查？例如，对部分特殊请求如“rm -Rf”或超高数值调整做了二次过滤？
是否做了关键操作的双保险？例如，数据库合并类的危险操作，增加了一个检查人审核机制？
另外，运维自动化发布平台是否保存有程序基线，并有一键恢复功能？
大公司的业务系统，运行十多年，开发人员你来我往数以千计，而发布平台每次仅更新部分代码（类似缝缝补补）。这样的后果是，可能根本没有人有一套完整的业务系统代码。
如果执行任意系统命令+缺乏基线，两者兼备，刚好又有人触发了执行操作，那么灾难性的后果就会突然来临。
毕竟，对于历史悠久的大型业务系统而言，老代码往往没人敢动，而且严重SOA化，从零重建的难度之大，也许需要几十个小时。而又因为这种极端情况下，很难形成一个强一致性的版本，所以重建成功往往只是灾难的开始，之后就是开发、客服和DBA陷入长期的疲于奔命之中。
2）缺乏安全机制
运维自动化平台一般由非专业开发人员实施，而且是给内部人员使用，主观上容易忽略代码安全和系统安全。
“上帝节点”是安全灾难的起点。
之前没有运维自动化，小米加步枪的时代，上千台服务器相对独立，还有各种堡垒机、动态令牌或私钥登录服务器等安全措施，想一个命令删除大批量服务器的程序，还真不容易实现。
运维自动化平台已然是“上帝节点”，天然的实现了连接到大批量服务器（甚至可能直接是root权限）。这样，为广大的黑客朋友带来了无限想象空间。
有朋友可能会说，我放在公司内网了非常安全。其实，现在黑客可以很容易的扫描到内网所有域名，识别到疑似运维自动化平台的域名，然后用常规或非常规手段入侵，然后就“一锅端”了。例如：
你的运维自动化平台是基于通用框架如Django么。一个常识是，越是流行的框架，已知漏洞、甚至0day漏洞越多哦。
3）忽略专业性
运维自动化越是充分的公司，隐藏的风险就越大。
即使一个再优秀的运维自动化平台，也不能解决所有运维问题。所以，如果忽略了对人员专业能力的培养，那么在某些需要人工操作的场景（例如机房迁移这类重大调试），问题就会报复性的反弹和爆发。
一次专业的调试，体现在对调试时长和调试效果的掌控上。调试时长必须可接受、并可控。
例如一次跨机房迁移，停业务10小时甚至以上，是很难被接受的；停业务10分钟以下，则是很令人愉快的。但这个的专业化要求很多，包括如充分的演练、更多的任务前置，保证只有必须的操作在调试期间进行。
可控性主要体现在调试节奏的把握，例如是否有快速可操作的回滚措施，保证如果预计调试不能如期完成，能提前预警并快速切回之前的系统状态。
当有重大调试需求时，突然发现中级运维人员没那么多了，初级运维人员缺少专业化锻炼和练手机会，“手生”，主管不敢用之；高级运维人员都已“金盆洗手”多年，自己不敢上手。
4）自得和忽略人文关怀
运维自动化平台上线后，运维人员可能会产生一种主观的优越感，并严重阻碍后续工作的开展。以前是开发追着运维打，运维往往疲于奔命，心力憔悴。现在神器在手，容易“多年的媳妇熬成婆”。。。
其实运维自动化只是解决了运维部分工作效率的问题，远没有解决运维的全部问题，外部门对运维的不满，可能涛声依旧，例如经常容易犯的“老板着个脸，说话直接不拐弯；需求老不及时完成，完不成也不说”等等。
运维自动化越是充分的公司，高层管理者（技术VP或CTO）可能产生一种错觉，运维人员是否可以靠边站了？甚至夸张些说，是否可以“卸磨杀驴”了？这种意识层的错觉或者说自我心理暗示，会导致各种多米诺骨牌式的效应。
如果高层忽略人为关怀，在某些极端情况下，运维自动化平台的高权限人员，可能“有意”利用上述提及的平台缺陷，进行极具破坏性的事情。。然后灾难性的后果，可能长时间难以补救。
结语
运维自动化的价值在于，将运维从繁琐的、例行、容易发生人为事故的工作中脱离出来，做更有价值的业务运维和服务运维。
所以，从这个角度来看，运维自动化既不是起点，也不是终点。运维自动化不是万能的，我们需要看清楚它的位置。
运维自动化，终归只是一个高级工具而已。运维的价值最终是要体现在业务上的：
体现的方式就是运维服务化，所以运维自动化（智能化）最终都要为运维的服务化服务。所以如何构建你的自动化系统最终要看你所支撑的业务需要什么样的服务。
所以，在做之前一定要弄清楚我们的目标，不要为了做而做，如果这样，结果就只能是呵呵了。
转载自
https://mp.weixin.qq.com/s?__biz=MzA4ODQwMDg1NQ==&mid=2247485483&idx=1&sn=39be4773b038e96b340fb33ebe0ad3a7&chksm=902bfe93a75c7785b101212a90281105dec9b3802c4debcbd44e4b2ad3f0305fef0593fcd8ec&scene=178&cur_album_id=1687560530007261186#rd
https://www.cnblogs.com/peter316/p/6287264.html
https://developer.aliyun.com/article/54429