大家在平时工作中是否有过这样的操作:
(1) 使用各种终端(如 xshell)登陆到机器里,执行一些命令. 比如看磁盘是否满了、查看一下 TCP 链接、看某个进程是否存在等等
(2) 如果服务是部署在多台机器的,还得挨个登录到机器里去执行一些命令
等等, 简而言之就是手动在多台机器之间徘徊. 也许我们会将一些常用的操作都记录到笔记里,下次直接复制粘贴命令到命令行. 但是, 整个周期还是很长的. 接下来要介绍一种基于 聊天的运维方式--chatops.
简而言之,chatops
就是以聊天的方式去快速完成devops
所承载的工作.
ChatOps 以聊天室,即沟通平台为中心,通过一系列的机器人去对接后台的各种服务,工作人员只需要在聊天窗口中与机器人对话,即可与后台服务进行交互,整个工作的展开就像是使唤一个智能助手那样简单自然。
下面整理了bearychat
和hubot
搭建机器人以及使用等.
https://github.com/510908220/chatops-examples
最近使用下来,不仅好玩,确实能提升效率。有兴趣的小伙伴可以一起交流~
1
timwei 2018-04-23 15:55:36 +08:00
跟 BotOps 差在哪?
|
2
f2f2f 2018-04-23 16:09:08 +08:00
感觉还是不如面板式运维方便。
|
5
mokeyjay 2018-04-23 17:43:03 +08:00
“聊天式”其实本质上跟你十几年前拨打电话跟着提示按数字键是一样的低效和恶心
连微信都知道公众号交互太弱鸡而搞了个小程序 除非你的语义识别能达到真人高中以上学历的水平,不然还不如开发个功能全面操作简便的 XX 面板 |
6
lfzyx 2018-04-23 17:52:24 +08:00
对于程序员来说,写一堆命令比跟人聊天更有安全感
|
7
510908220 OP @mokeyjay 这种机器人只是很明确的操作,并不需要多复杂的直指令。只是改进一些现有底低效率方式,一种新的工作方式。当然不是适合所有场景。
|
8
cominghome 2018-04-24 16:04:15 +08:00
覆盖场景不够,而且只能进行部分简单的工作没什么意义,反而加大运维负担。就拿你的例子的场景来说,正常的运维应该是这样的:接到报警提示 tcp 链接异常(服务器异常)-->登录服务器确认-->处理异常,而不是没事就和机器人聊天。如果能把一些简单故障的处理也自动化倒是还有一些价值
|
9
510908220 OP @cominghome 恩,我这个例子是不太恰当。平时我还有这样的场景: 有时需要去根据一些设备 hash 去查询一些访问记录等,一般是有人找我排查时,我才会去查。对于这种我觉得还蛮适合的~
|
10
petelin 2018-04-24 18:24:41 +08:00
非常的不方便, 使用场景有限, 只适合少输入, 多输出的场景, 比如查询, 而不是创建, 复杂查询
|
11
cominghome 2018-04-24 21:27:07 +08:00
@510908220 事实上这类需求最高效省事的办法是写脚本,在有成熟运维系统、工具的情况下就更简单了。你这个如果要接下去做的话,我倒是觉得可以做成告警工具+自动处理的方式,类似于监控系统-->发现可能存在的异常(例如 cpu 负载突然拉高,网络流量突然爆发,磁盘增长速度过快)-->给出故障分析-->给出建议处理方式-->如果得到用户确认就按照指示处理,如果没有得到确认就挂起。而连续 xx 次都是这样以后也就自动这样处理。(好吧,就是所谓的智能运维)
|
12
510908220 OP @cominghome 很全面。你这个描述的是监控的场景. 这种聊天方式对于一种交互式运维还是会有效果的.
|
13
soulmine 2018-04-25 11:16:51 +08:00
还以为是 slack........ 这个的应用环境是执行命令啥的 比如突然想看负载 又懒得登 就打一局 htop 啥的 返回一串数据
|