浅谈Atlassian产物搭建的神速管理系列,那是有赞

2020-01-15 作者:亚洲城动态   |   浏览(174)

线上故障是指提供给客户使用的IT服务全部或部分不可用,包括服务性能的降低,如:服务延迟导致用户体验变差。

准备把敏捷管理的专题在今年完成,主要谈一下Atlassian的实践,先做一下搬运工,讲去年写的两篇弄过来。

在创业前期,为了抢占市场先机,产品新功能的发布速度追求往往优先于其质量,埋下了很多技术债务,部分技术债务的爆发会引起线上故障,造成客户的体验下降或经济损失。

Dream big, work smart, deliver fast

故障管理的目标是“尽快恢复服务到正常运行,并且最小化对业务运营的不利影响,从而尽可能地保证服务质量和可用性的水平”。

使用Atlassian的产品已经有三年多,但是大部分主要以JIRA和Confluence为主,2015年年初加入一创业团队负责技术团队的搭建,从零开始通过部署Atlassian产品、制定开发流程,由于创业团队人手不够,自身也参与了大部分的开发工作,开始有一些考虑不周的地方,随着工作的展开不断调整,通过半年的努力也引来了第一轮的投资,可能创始人国企非技术出生背景的关系,在对技术团队的价值看待上分歧很大,最后还是选择了离开。机缘巧合,马上又加入了另外一个创业团队,依然主要负责技术团队的搭建。这次吸取了之前碰到的一些经验进行改进,并且加入其他一些想法。下面主要就这两次经历,简单谈一下Atlassian的使用经验,可能还有不少问题存在,还请各位大牛指点!

在故障发生后,故障紧急处理小组会定位、分析和恢复故障,并在故障恢复后对故障进行Review和总结,制定出可执行的Actions,以提高故障处理效率和避免类似故障再次发生。


下面将为大家简单介绍有赞的故障管理实践。

目前我们使用的Atlassian产品

  • JIRA:用来做项目管理、流程控制、缺陷跟踪、版本管理等

  • JIRA Agile:JIRA的插件,主要用来做Scrum敏捷管理

  • Confluence:团队协作工具,文档管理,任务管理,资源管理

  • Fisheye Crucible:用于做代码评审

  • Bamboo:用于构建持续交付的测试环境

  • HipChat : 用于团队沟通,主要看中可以整合JIRA和Confluence等的实时提醒


故障处理流程介绍

其他工具

  • SVN:代码版本库

  • Nexus:私有的Maven仓库,通过VPN快速下载JAR包(天朝网络大家都懂的)


有赞使用JIRA作为跨部门协作工具,线上故障管理也借助于JIRA。我们制定了下面的故障处理流程,故障JIRA工单遵循该工作流,而故障Action(s)会被建立在对应的故障JIRA工单子任务中,子任务的工作流为JIRA默认工作流。

产品安装

安装过程比较简单,这里不加赘述,主要说一些可能要注意的点(大家若在安装中有疑问问题,欢迎留言交流):

  1. 由于用户不多,这里没有使用Crowd做统一用户管理,所有用户都使用JIRA的用户管理,因此先安装JIRA,然后再安装其他的产品,并将用户管理配置到JIRA的服务器上。
  2. 默认的安装包中不包含mysql的驱动,需要自己复制到lib目录下,并重启服务
  3. Bamboo单独安装一台服务器,作为持续交付的测试服务器。(具体的部署机器的分配视具体配置和资源使用而定)

确认故障与通知协调人

产品使用

我们采用Scrum的敏捷管理模式,达到快速迭代的效果。下面通过从产品设计开始到开发、测试的过程描述整个软件过程中产品的使用方法

准备工作
: JIRA中创建Project,每个Project管理一个产品
: 修改流程,增加Code Review步骤
: Confluence中创建对应的Team Space
: SVN中创建项目版本库,并在Fisheye中配置该库
: Bamboo所在机器上安装Maven、Java、Tomcat、Nodejs等需要的产品运行环境,并将Maven的仓库路径配置到我们的Nexus服务器所在位置
: 为JIRA、Confluence等根据需要配置邮件提醒

产品设计(Confluence)
: 产品经理在Confluence中完成所有产品设计,编写产品需求文档,每个产品需求文档为一个Epic、多个Story(新版Confluence支持在Confluence中直接创建JIRA的Issue,非常便捷)
: 为达到快速迭代的预期,每个Epic的开发测试的周期尽量控制在1个月,其中具体执行分2-4个Sprint完成开发。
: 附上产品设计原型

会议纪要(Confluence)
: 产品设计完成后,需要经过多次迭代修改,最终定稿,所有会议内容需要记录和转换任务
: 每次会议前创建会议页面,并指定参加者和编写会议讨论内容,只要配置过confluence的邮件提醒,会给参与者发送邮件提示。
: 会议过程中实时记录会议讨论结果或转化的后续任务,并设定任务的执行人和截止时间,用于跟踪任务情况

开发预估(JIRA JIRA Agile)
: 完成产品设计后,开发经理在JIRA Agile中对Epic中包含的Story先做Story Point评估,有需要再分割的任务创建Sub-Task并分配具体执行人。
: 同步进行UI设计和实体设计

冲刺制定(JIRA JIRA Agile)
: 完成开发预估之后,开始执行阶段冲刺(我们采用1-2周一个冲刺),根据评估进行分配。
: 每次冲刺结束后,需要创建冲刺回顾文档,分析本次冲刺中好的部分和做得不够的部分,以指导下一次冲刺指定的标准

持续交付(Fisheye Crucible Bamboo)
: 冲刺制定之后,进入开发阶段,开发人员的代码提交,通过Crucible完成Code review
: Bamboo构建策略采用定时构建,我们设置在晚上12点进行构建,从SVN中检出代码,跑单元测试,打包,自动部署到Tomcat上,并发送构建报告给项目成员,第二天产品经理和测试人员就可以通过测试环境对完成的任务进行测试,若发现问题,则进入JIRA创建BUG,待后续迭代修正

当收到客户、内部员工或监控上报的潜在故障时,报告人会尽快确认故障的有效性。

产品购买渠道

通过CSDN购买:http://atlassian.csdn.net , 入门版本为99¥
通过Atlassian官网购买:https://www.atlassian.com, 入门版本为10$
相比之下,官网更便宜一些,第一次搭建的时候在CSDN购买,后来发现了后者,第二次搭建的时候部分产品在官网购买了,相差不大,大家自己考虑咯。

当确定是个故障后,会提交一个故障JIRA工单,并通知故障协调人(来自研发效率团队,主要负责业务与技术部门之间的信息同步和协调)。

总结

本文主要描述一下各个产品在我们目前团队的过程管理中起到的作用,可能真正用的时候读者还会有不少疑问和不解的地方,欢迎留言交流,后续有空时候针对每个产品再详细写一些经验分享。比如:Bamboo的中文资料一直很少,可能对初次使用有一些迷惑。

协调人确保公司内业务部门、技术和产品部门被通知到位,同时将故障上报到“可用性保障微信群”里,故障原因排查和讨论会在该群里或拉单独的故障处理群进行。

定位/处理故障

为避免无关消息干扰,故障处理人组建故障紧急处理小组(在微信群里或坐在一起),以提高故障处理效率。

故障处理人在定位到问题后需将故障原因和预计多久修复同步给协调人。对于处理时间比较长的故障,紧急处理小组会每隔半小时对相关业务部门同步一次故障处理进展。

故障恢复

如确定是发布引起的故障,需将代码回滚到故障前的某个稳定版本。

故障恢复后,故障处理人需跟业务影响方确认是否有数据需要修复。如有,需将影响情况反馈给协调人,并配合业务方尽快修复数据。

组织故障Review

故障Review一般安排在故障处理结束后24小时内,包括故障过程回顾、故障原因分析、改进预防措施制定、故障定级等,其产出物为:

故障分析报告。故障定级分为P1、P2、P3和P4四个等级(依次降低),每个业务组都有特定的等级定义,主要从业务影响面和影响时间来确定。目前使用的故障报告模板如下:

同步故障报告

故障Review参与人一般是故障处理人、协调人、责任人及责任方组长,故障报告人视情况自愿参与。

为了让所有技术小伙伴都能了解到故障信息,故障责任人需将最终版的故障报告同步到产品技术群。

建立每个Action JIRA子任务

故障责任人在JIRA故障单下创建子任务,每个子任务对应一个故障Action,子任务的“到期日”字段需被更新成:Action的Deadline,并将其分配给Action执行人。

故障与故障Actions跟进

JIRA看板是个很直观的工具,支持在规定的工作流之间移动任务板。我们使用JIRA的kanban board来跟进故障及其Actions(如下图),顶部快速过滤器可以快速访问各技术业务组不同状态下的故障或Actions信息,横向上拆分成3个泳道:

故障、逾期故障Actions和待处理故障Actions。

如果某个Action的到期日已经到了,该Action任务板会显示在“逾期故障Actions”泳道中,否则会显示在“待处理故障Actions”泳道中,故障协调人会定期跟进下逾期故障Actions的执行,并将逾期的故障Actions同步到产品技术群里,以提醒Action执行人及时处理JIRA。

故障数据分析

通过分析故障数据,我们可以发现问题在哪里,并进行改进。目前故障数据主要记录在JIRA和Confluence上,我们会将其按特定格式备份到Numbers中,从不同角度分析这些故障数据,如:

每月故障数对比、每月故障处理时间对比、近两月故障等级占比分布、近两月故障类别占比分布、近两月故障来源对比和近两月各业务组故障数对比等。

结合每月发布数据和线上问题数据的综合数据分析,我们得出了“发布次数很多的月份,其线上问题和故障数也相对较多”的结论。为了减少故障发生率,我们需要减少发布频率和规范发布流程。

小结

根据当前存在的问题制定出一套流程不难,难在对流程执行的跟踪和监督。有赞线上故障处理流程由研发效率团队负责跟踪和监督,确保了每个故障都能经过Review,并形成完整的故障分析报告,同步给所有技术小伙伴。同时,每个故障Action都是可执行的,且有明确的执行人和Deadline。

经过一年多的故障管理,我们不仅沉淀了宝贵的故障数据,为改进方向提供了参考,也增强了小伙伴的故障意识,对线上环境的敬畏之心和对故障的紧急处理意识。

关于“故障管理”,我们只迈出了一小步,还有诸多待改进的地方。例如,我们目前主要管理了线上的故障,对公司内部系统故障并没有管理起来;目前大家了解故障信息的途径是:

JIRA、Confluence和技术报表,缺乏一个公共的故障检索和自动生成故障报表平台;我们的事件管理(Event Management)水平还很低,很多故障是由客户上报,而不是由监控系统先发现。

注:本文转载自有赞技术团队博客,作者杨波。

本文由yzc216亚洲城发布于亚洲城动态,转载请注明出处:浅谈Atlassian产物搭建的神速管理系列,那是有赞

关键词: 亚洲城官网 yzc216亚洲城