一.说明
最开始培训完入行的2年里，进的几家公司和面试遇到的基本都是机器在200个虚拟机以下，运维加上我也就1-2个人。
这种都是自己说了算，做了什么操作自己记住就行了，添加权限也都是开发说一下这边就给加上了，流程配合之间都靠嘴对嘴的传递，当然也可能用qq和微信。
工作环境还是很重要的，现在待的项目运维多的时候5个，虚拟机300往上，还有一大堆别的云产品要维护。这就有必要进行分工了，而不是大家谁闲着就做，那会导致需求人找不到谁在负责，而且负责人也会来回变动。
那需求就来了，根据日常工作发现如下问题： 1.开发不知道找谁能把这件事做成 2.开发来申请添加权限、用qq之类的进行说明描述 3.因为每个人负责一块，都参与工作，没人知道整体进度 4.某个运维做了一些操作别人不太清楚 5.这块他负责的，现在他请假了，接手后不知道怎么做
那看看开发怎么怎么解决上述问题的： 1.产品经理有需求要提jira 2.在jira上有任务表，可以看到每个人接到的任务，涉及哪一块 3.代码写完后合并到master分支要开发组长去确认，注释也写的很多
具体还会有相应的工作流，将每个需求都从头到尾追踪好，后面上线测试环境甚至生产环境都有相应的管理流程。
二.初代设计
最开始想的是在内部confluence（一个笔记网站）上记录下我们有哪些任务要做，按照日期划分，每天都记录下，任务名称后面写上名字。
当然对于外部的需求，例如加权限，解决一些jenkins发版上的配置错误等等都是完成后来这里补。
现在想想真的很蠢，这记录和没记录的区别完全不大，虽然知道谁什么时间做了哪件事，但维护起来实在费心费力，和其它组的交互也是原始的嘴对嘴交流。
同时这个也完全看不出[任务进度]、[谁在划水]、[某类任务数量]、[当月故障数量]等等，也就是只记录了，但统计非常困难，需要人工去数。
在发现开发用jira后，探索了一下，发现确实很好用，可以实现我们的需求。通过搭配钉钉通知和看版，再建立好清晰完善的工作流程，可以最大效率避免在开发流程上花时间。
三.效果展示
用jira建立2个项目，一个是对外工单用于外部需求的处理，一个是对内工单只内部使用记录任务。
给区分开是因为夹杂在一起会很乱，内部都好说就几个人大家都按照任务进行类别创建，比如购买服务器就建立[资金管理]任务，处理故障就建立[故障处理]任务。
但开发是不管这些的，人家不管是申请权限、处理报错、申请资源全都是[故障处理]这个默认问题类型。所以要精简为2-3类最好，这里是权限和其它类型。
外部任务： 1.权限申请，这里权限申请会搭配钉钉脚本做超时通知，用户要定时续期权限，当然可以调整更大的选项，例如6个月。单独添加申请人选项，是因为申请者可能还没有jira，或者是外包人员
当权限超过规定期限，会给jira的工单发布者和管理员均发送一个钉钉消息
2.其它任务
内部任务： 1.服务管理，这里是内部的任务，例如发版、搭建服务、备份数据等等操作。对于一个大任务一定要拆开成版本，也就是合集，把任务去细化。
不然你随便写个k8s优化那就假大空了，没有一个目标和划水没有区别，做2天感觉烦躁就懒得做了，就没有意义了。同时对于生产等重要操作，要编写配套任务的《操作用例》，你没猜错，就是对标测试的《测试用例》。因为运维不求快求稳，文档操作不出事，比出现问题后补救要成本小得多。
2.报警可以选择几个类别，这里后面会做zabbix联动建立jira任务，其实zabbix本身就可以针对每条报警做处理和记录，但放到jira是统一管理了。
3.其它类别，都是自己人，可以把问题做的细致一点，这样利于后面用jira的筛选器做统计。比如统计某人这个月发版多少次，鼠标勾选几下就出来结果了。
像我自从工单建立后，正式生产发版一共10次
四.工单运作流程
对于外部工单，设置为默认经办人是运维组长，到他那里后，看到钉钉通知，再进行后续任务分配，将人员调动起来。
可以根据jira中查询每个人的任务量，再到grafana上进行综合展示，这里还没做完，后续再补图，相当于做内部的《看板》，将大家的任务状态用大盘做可视化。
这样就会通过大屏看板一目了然，可以找到谁这周任务最少，或者做的拖沓，本来[ELK日志分析]建设这个大项目，里面有3个jira任务，预计是14天完成，结果第一个人任务2周过去了还没完结，说明有问题。
对于这种，说明任务太有挑战性，就多给他分配外部工单进行锻炼，腾出其它组员的时间，晚上加班/值班，也都多安排他来。工单尽量要区分清楚，用强制选项的填选来规定，而不是都在备注里填，很多人懒得去备注里写。
