Loading [MathJax]/jax/output/CommonHTML/config.js
前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >运维工单的应用

运维工单的应用

原创
作者头像
用户1348170
修改于 2021-07-14 10:07:20
修改于 2021-07-14 10:07:20
1.6K0
举报
文章被收录于专栏:52test52test

一.说明

最开始培训完入行的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周过去了还没完结,说明有问题。

对于这种,说明任务太有挑战性,就多给他分配外部工单进行锻炼,腾出其它组员的时间,晚上加班/值班,也都多安排他来。工单尽量要区分清楚,用强制选项的填选来规定,而不是都在备注里填,很多人懒得去备注里写。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
运维体系之做好一个纽带(下)
系统的优化比较常见,一般是更改配置文件,使得服务可以承接更多并发,可以抗更多压力。
用户1348170
2021/07/09
4660
运维人必看:DeepSeek如何落地运维场景
作为一名运维工程师,你是否正在寻找一种更智能、更高效的方式来管理复杂的IT基础设施?DeepSeek(或类似AI工具)可能是你的答案。今天,我们将深入探讨如何将DeepSeek融入运维工作,并提供多个实际场景的详细解决方案。
lyb-geek
2025/03/06
1.5K0
运维人必看:DeepSeek如何落地运维场景
做运维的感悟(做运维需要考虑事,运维组织结构,运维学习地图....)
不过大公司会专门做某一部分,例如应用运维不需要关注测试和安全等方面,但建议都学学,触类旁通有好处。 有这些基础,进到公司就可以去完成基础的建设工作了。比如会安排你搭建服务,整理资产报表,清理一些日志,这些基本工作可以帮助你了解公司当前有哪些服务,各种服务之间是如何运作的,之后再慢慢参与到业务中,薪资一线城市可以达到6-10k左右。
iginkgo18
2020/12/23
6.7K0
做运维的感悟(做运维需要考虑事,运维组织结构,运维学习地图....)
自动化运维中的脚本管理和工单管理
蓝色的部分是我们已有的部分,另外的部分是我们当时做得不好的地方。 当然这个过程说起来都是辛酸泪。都是一点一滴的改进。
jeanron100
2018/08/22
3K1
自动化运维中的脚本管理和工单管理
运维规范:线上故障处理的流程模板
建立专门的应急群,将这些事故产品的关键角色纳入其中,当有故障发生时会第一时间在群通报。
星哥玩云
2022/06/21
3.2K0
运维规范:线上故障处理的流程模板
统一运维平台建设的一些思路和实践
企业构建一站式运维平台的目的是为了提升运维效率。那么一个成熟的运维系统应该要解决哪些问题呢?笔者认为首先是运维对象要被管理起来,然后是监控这些对象,接着是这些对象的自动化运维,最后是所有的运维操作都要有所规范。概括起来对应的系统就是CMDB、统一监控、自动化平台、ITSM,如下图所示。
用户1107783
2023/10/31
1.3K0
统一运维平台建设的一些思路和实践
Zabbix与乐维监控对比分析(八)——其他功能篇
前面我们详细介绍了Zabbix与乐维监控的架构与性能、Agent管理、自动发现、权限管理、对象管理、告警管理、可视化、图形图表及网络功能方面的对比分析,接下来我们将对二者其他功能进行对比分析。
乐维_lwops
2023/01/13
3460
Zabbix与乐维监控对比分析(八)——其他功能篇
运维体系之做好一个纽带(上)
运维的工作通常是针对现有系统的,例如服务器、在运行的服务、监控、添加白名单、添加权限等等,是宽泛而繁琐的,少有建设性的内容。
用户1348170
2021/07/09
6370
工单管理模块建设思路
工单是运维工作里面的硬通货,在多年之前我们口口相传,no 工单,no work,但是似乎在很多公司里面对于工单的管理都不够给力或者给予的重视程度有一些落差。
jeanron100
2018/08/22
2.2K0
深度好文-饿了么进化史(你一定会有收获)
大家都知道这两年饿了么的发展迅速,作为一名运维人员如果你工作在饿了么,你可曾这样分析过?之前分享过一篇关于饿了么的文章。 大家好,首先,先简单介绍下自己,我是徐巍,目前在饿了么负责基础设施的运维及开发工作,早些年就职于PPTV、携程、游族等公司,也算是一个运维的老兵了。饿了么成立于2008年,2014年底开始迎来业务的大规模爆发性增长,2015-2016年饿了么进入高速发展期,业务和服务器的增长都在数十倍的规模,这种大规模的增长必然带来很多挑战,本文将通过饿了么运维基础设施的进化史和大家分享不同时期应
老七Linux
2018/05/31
2.6K0
IT运维支持如何转化为服务
关于IT服务能力的介绍,本期标题中主动式、可量化、构建IT运营服务三个关键词概括了我对IT服务能力的理解,其中IT运营服务在上一篇《IT运营转型中的ITOM》作了一些分析,本篇从ITIL、ISO20000、ITSS方法论对服务做补充。另外,IT服务能力主要以ITSM方式提供IT服务,关于ITSM的实现方式在之前关于servicenow的文档中也作了介绍,本篇不介绍在ITSM上的服务具体实现,而是从主动式、可量化两个角度进行扩展。
彭华盛
2020/03/06
1.8K0
YesDev多功能项目协作,推荐一款简易强大的研发协同工具
YesDev是一款简易强大的研发协同工具,可以帮助每一个团队,提升产品研发效能,结合敏捷开发和DevOps双引擎,实现研发全流程扁平化协作和闭环管理,解码研发“黑洞”。它的作用和价值是帮助每一个产品研发团队,持续、稳定、高效交付更有价值的软件!
dogstar
2023/01/14
1K0
YesDev多功能项目协作,推荐一款简易强大的研发协同工具
【重磅】大众点评运维架构图文详解 @高效运维
本文根据高效运维系列群「运维讲坛」的嘉宾分享整理而成。运维讲坛,邀请国内运维领域优秀技术专家作为分享嘉宾,其中线上分享每周一次,线下沙龙活动每月一次。欢迎点击上面蓝字,关注“高效运维”公众号以了解更多运维讲坛活动、第一时间查阅原创文章,请参见文末。 本次运维讲坛线上分享沙龙活动,特别感谢群友@陶豆及华三通信(H3C)。H3C连续多年在网络市场国内和全球的份额名列前茅,服务于国内百行百业。涉及领域包括数据中心交换、路由产品、SDN、Overlay、NFV等;长期合作伙伴包括3BAT、京东和小米等。 编辑 •
小小科
2018/05/02
2.5K0
【重磅】大众点评运维架构图文详解 @高效运维
COS提效实践:如何实现发布变更的“快”与“稳”
导语:随着云存储业务蓬勃发展,节点数不断扩展。在数十万节点的庞大系统中,如何做到一周内完成全区域覆盖,并杜绝版本发布中的人为失误?文章围绕对象存储(以下简称COS)整体的发布演进,从发布效率的极致提升,平台发布标准化外包化上展开,讲解COS发布成熟度如何提升(当前level2+),希望提供业务通用的高质量变更模式与提效参考。
jackie慢慢来
2022/10/25
1K0
COS提效实践:如何实现发布变更的“快”与“稳”
普元DevOps平台的安全可靠设计
普元DevOps平台覆盖从需求到运维,力求帮助团队提升工作效率、保障系统质量。在安全可靠层面,平台需要考虑自身如何跨环境且流程合规,还需保障所生产的软件的安全可靠。
yuanyi928
2019/10/31
8470
曾老湿带你了解运维需求-实现自动化运维平台
1)崩溃率:通过分析日志(底层Logstash将日志导入到数据库中),实时获取日志的状态码,计算出4xx,5xx的状态,和当前日志总量相比,得出结果,通过获取数据库中的数据,以画图的形式展示在页面中。
DriverZeng
2022/10/31
7440
曾老湿带你了解运维需求-实现自动化运维平台
运维不仅仅是 Linux,居然还要知道这么多?
运维不仅仅是懂Linux就行,因为还有一大部分的Windows运维,向windows运维人员致敬。 当然我们这篇文章不是说运维除了懂Linux,还要懂Windows,而是涉及运维的其他方方面面。 如:环境部署、排错和调优、备份、高可用和集群、监控告警、安全和审计、自动化和DevOps、虚拟化和云服务。 环境部署 一开始这个世界是开发的,然后才是运维的。 开发实现产品逻辑,将产品开发完成后,然后提交运维进行部署。此时允许就需要准备好部署环境,如部署在Linux服务器上,安装相应的软件,如Apache、Ng
码云Gitee
2018/03/29
1.1K0
运维不仅仅是 Linux,居然还要知道这么多?
基于Jira的运维发布平台的设计与实现
环节看似简单,但是中间其实是有断层的。一般企业在走上线流程都是通过一些公共渠道,比如邮件、钉钉、飞书的流程,这些都很难和运维执行上线发布平台进行关联上,而且也不够直观。所以我们就需要解决以下几个问题:
没有故事的陈师傅
2021/06/24
1.6K0
基于Jira的运维发布平台的设计与实现
京东基于Zabbix告警治理优化实践长文回顾(含PPT)
许泽明,京东集团SRE。本文整理自许泽明在2021Zabbix深圳大会发表的演讲。
Zabbix
2021/09/08
1.2K0
运维不简单
好长一段时间没有更新公众号,回忆当初开这个公众号的初衷是为了将工作中一些零散的知识点汇总整合,形成为一个相对完整的知识体系。客观的讲,通过总结一些工作心得,让自己的运维知识体系的建设有些效果。年初与一个行业大牛的朋友交流时,在听到他年轻时在思科的一些关于将工作方法升华为方法论,比如“监、管、控”、“新网点”理念,并推动整个行业建设时为之一震。这个触动让我有了让自己的运维知识体系建设做第一次飞跃的打算,即如何将知识体系通过一个主线串起来。关于这个主线,找过一些朋友做了交流,比如“风险可控”、“一体化”、“更高效更优化的资源配置”、“可扩展性”。由于自己主要身处一线运维团队,所以选了“可扩展性”的主线,接下来打算根据这条主线,不断完善知识体系,目标是体系化的整理知识体系,主要从组织、流程、工具的可持续整合。
彭华盛
2020/03/06
1.6K1
推荐阅读
相关推荐
运维体系之做好一个纽带(下)
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档