运维事项kanban
kanban内容主要是分为四项
- 日常事务：功能开通，问题查询等等事务性的工作。
- 故障：回顾。主要是故障处理的时候谁都没有空去写jira。但是回滚的模板可以有。
- 运维开发：一些是运维体系内的开发工作，还有一些平台型的开发工作。
- 项目：比如es的升级，kafka的升级或者迁移，升级扩容等工作。
既然是分为了不同的task类型，那我们还是需要为每个task类型设计好workflow
- 日常事务
- 创建
- 开始
- 结束
因为日常事务一般都是比较简短时间就可以完成。但是这里有个特殊的是，当一个日常事务如果一直发生，那就应该转成一个项目或者运维开发又或者是业务研发的task。
故障
我们要用正确的眼光去看待故障。首先故障是不可避免的，但是我们需要有方法比如业务数据的变化来判断系统是否有异常等等。
对于我们认知范围内的故障，需要通过StackStorm这样的工具是修复掉。这个需要在故障回顾总结的时候建立瑞对应项目task或者运维开发task去完成。
而对于认知范围外，但是又会导致业务数据异常的故障，首先是加强报警机制，其次是复盘好同时推广到其他组件是否会有类似问题等等。运维开发
- 设计
- 实现
- 测试
- 上线
这里每一个步骤都是可以回退的。同时由于有些开发项目会比较庞杂，那我们需要分解好，第一个运维开发task需要在一周内可以完成workflow里的一个流程。不然这个项目就很难进行跟踪了。
我们这里定义的就是一个纯运维开发的项目，比如写一个报警系统，写一个迁移程序等等。
- 项目
这个其实对于我们团队最重要的部分。一个正常的SAAS产品会一直在持续迭代中。所以需要思考的问题会相当的多。
比如最近redis出5了，这个支持了stream, 我们的系统中是否需要引入，不引入会怎么样，引入的话需要定义那些使用规则。
elasticsearch出7.X了，它支持了哪些新功能，去了哪些特性的支持，性能怎么样，升级需要如何迁移数据？ 是否需要研发升级对应进行升级。工作量如何进行评估。
因此对于项目来说它的生命周期就是：
- 调研
- 方案
- 沙箱验证
- 线上验证
当然这些每个步骤都是需要可以回退的。
以上都在jira里建立了对应workflow来进行了。后面再设计下对应的kanban就齐活了。不过关键的还是要让大家把任务提到jira中。