可视化会给你意想不到的答案！

有时候突然会把几件不搭边的事情联系起来，竟然能够找到一些共通的地方。我在琢磨最近的几件事情的时候，脑海里不由得浮现出几个字：“半成品”

我是蛮反感工作中的半成品的，说有吧，使用效果一般，说没有吧，也投入了一些时间，概括一下就是投入和产出严重不成正比。

另外一类情况更偏于主观，做任务的人感觉一切都妥当了，但是验收的时候，发现不是设计理念的问题就是任务的精细度上面比较粗糙，如果本着差不多就行的态度其实也能过去，但是显然以后的事情谁能说的了，真要用到的时候，代码逻辑都忘差不多了，重新调试改动，这个工作如果前期能稍微充分难一些，也不会有很多返工。

所以在这件事情上面，我发现以前对自己，对团队成员的要求有些松散，以至于稍微带点要求和质量标准，就会感到大家有些吃力，其实对于职业发展来说是有害的，从0到1的构建主要为了效率和快速迭代，可能在一些质量标准上面可以打折扣，过度要求会有些刻薄，但是守江山更难，技术维护也是，都希望时间的边际成本能够越来越低，在已有的基础上构建和改进，那得下真功夫。

我举一个最近和半成品对抗的小例子，也是鞭策自己能够继续按照既定的想法往前走。

这是数据库软件的安装部署的例子，按理说这是很简单的一件事情了，如果要抠命令，基本都是个位数的命令，但是有一些需要额外补充的地方。

 

自动化运维工具的优势和必要性：

• 提高效率：由程序自动化操作，有效地降低运维人力资源的投入，也让运维人员的精力得以释放并投向更为重要的领域。
• 操作的标准化：将原来许多复杂、易错的手工操作实现统一运维操作入口，实现运维操作白屏化，提升运维操作的可管理性;同时，减少由于运维人员情绪带来手工误操作，避免“从删库到跑路”这样的悲剧的发生。
• 运维经验能力的传承：运维自动化工具将原来许多运维团队积累的经验以代码方式总结为各种运维工具，实现自动化和白屏化的运维操作。运维团队的后来者，可以有效地继承、重复使用并优化它们。这种代码化的工作传承，将个人能力转变为团队能力，并减少人员流动带来对工作的影响。
• 构建自动化运维体系就必须以运维场景为基础，这些运维场景是在本企业内反复迭代和打造，是企业中最常用的运维场景。
• 比如常见的运维场景：软件安装部署、应用发布交付、资产管理、告警自动处理、故障分析、资源申请、自动化巡检等等。因此，整个自动化运维体系建设时也应支持多种不同类型的自动化作业配置能力，通过简单的脚本开发、场景配置和可视化定制流程实现更多运维场景的实现。

用户体验

用户体验这一层要说的是，作为SRE来讲，从用户的角度来保证业务的稳定性和可用性才是最终目标。这个才传统意义上的运维人员是不会关注这一点的，因为大家通常只会考虑到我底层运维的系统或底层资源是否稳定，但实际上整个业务的稳定才是SRE需要关心的问题，而业务的稳定性和可用性通常需要站在用户的角度来模拟和衡量整体的可用性和可靠性。

在前面提到的所有SRE相关的工作范畴，无论是监控、事故响应、回顾、测试与发布、容量规划以及构建自动化工具，无非都是为了提供更好的系统用户业务体验而服务的。因此，我们在运维的过程中无不需要注意关注系统的用户体验。

而在实际运维工作中，我们往往可以通过应用日志、监控数据、业务拔测等业务相关的用户体验信息。在运维数据平台中，通过这些用户体验监测数据之间的关联和串联，重现用户的最终业务调用链路以及各应用环节对性能数据的关系。最终形成从业务用户体验数据入手，逐步实现系统运行状态数据、设备运行状态数据链路的打通，让运维体系实现以最终用户体验为中心的目标。

这些用户体验的信息，对于运维团队掌握客户整体的用户体验情况、系统可用性的监测以及系统针对性的优化提供着无可替代的作用。

其实，SRE运维体系更为强调以用户的体验为核心，以自动化和运维数据为手段，实现应用业务连续性保障，从这个点出发，我们会发现和以往的传统运维还是有很大的区别的，我们不再仅仅是单纯的安装和部署工程师，我们需要通过一系列的技术手段来不断保障上层业务的稳定性和可靠性。

（编辑：鹰潭站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!