由于运维的琐碎、故障出现的不确定性以及解决问题的不可控性的存在，所以让运维人痛并快乐着。
运维的角度看：好的架构不是设计出来的，而是一步步的演进出来的。
命运就是这么难以捉摸,当你拼尽一切前进时才发现前无大道,想放弃一切后退之时却后路尽绝,最后生无可恋的纵身一跃时,希望却不知何时悄然而至。
? 运维自动化平台构建
第一阶段：标准化
OS级别基础环境一致，配置文件统一管理，软件安装目录一致，操控方式一致，监控方式一致，日志格式一致，标准化基础建设以便将来使用起来方便。
第二阶段：自动化
减少响应时间，减少人为因素的故障，对业务流程进行固化，将手工脚本化为界面可操作系统，权限管理聚合在一起，统一管控服务器等。
第三阶段：平台化
相对于自动化来讲平台化，讲究的更为人性化，屏蔽硬代码，使各方人员的操作习惯形成工作流，然后给大家更大的自主权。比如可自主的申请权限操作、可自主的发布游戏版本、可自主的查看各集群报错等。
? 运维任务调度平台构建
游戏运维日常内容种类繁多、零散、多变，当以定制化系统来应对时，会经常需要麻烦开发人员改动代码来适应运维场景，所以借鉴OA、CMS系统定制化工作流以此来应对，这样减少开发人员相应的工作量，也可以使运维利用自己最熟悉的 shell、python在不改动页面的前提下，尽快完成功能的开发，加快项目的落地。
第一：定制工作流
基于运维人员对各个工作流统一命名、统一部署、统一使用，使得基础环境一致性得以落地使用，并将日常工作内容固化。
工作流元素：工作流(多个)任务节点(具有优先级)(多个)进程节点(具有优先级)
工作流参数：在执行过程中可替换
在定制过程中尽量保证工作流的原子性，一个工作流只做一件事。不要出现歧义
第二：执行工作流
定制的工作流可在任意集群上执行，执行工作流，工作流上可填写所需变量内容。每个任务节点单独展示，使运维方便定位问题，方便定位发生在哪个服务器。
第三：工作流程执行引擎
工作流之间没有优先级、任务节点之间有优先级、进程节点之间有优先级，所以 工作流之间是并行关系，任务节点之间是串行关系，进程节点之间是串行关系。在描述这一切时忽略了服务器之间并行的关系，而所有的任务节点其实是作用到服务器上，同一个任务节点的不同进程节点是在同一台服务器上执行的。在工作流数增大或者单个工作流延时比较长的情况下，需要考虑分布执行的情况，用生产者和消费者加锁的方案解决。
个人微信公众号，欢迎各位交流
延伸阅读
- ssh框架 2016-09-30
- 阿里移动安全 [无线安全]玩转无线电——不安全的蓝牙锁 2017-07-26
- 消息队列NetMQ 原理分析4-Socket、Session、Option和Pipe 2024-03-26
- Selective Search for Object Recognition 论文笔记【图片目标分割】 2017-07-26
- 词向量-LRWE模型-更好地识别反义词同义词 2017-07-26
- 从栈不平衡问题 理解 calling convention 2017-07-26
- php imagemagick 处理 图片剪切、压缩、合并、插入文本、背景色透明 2017-07-26
- Swift实现JSON转Model - HandyJSON使用讲解 2017-07-26
- 阿里移动安全 Android端恶意锁屏勒索应用分析 2017-07-26
- 集合结合数据结构来看看(二) 2017-07-26
学习是年轻人改变自己的最好方式