锐客网

  1. 首页 > it技术 > >

DevOps Master凤凰沙盘的学习体验

devops

一直想系统化地学习DevOps 知识体系，工作中推动DevOps很需要，去年的DevOps 线下活动中接触到了《DevOps 精要业务视角》。
国庆假期啃完了《DevOps 精要业务视角》、《DevOps 实践指南》、《持续交付：发布可靠软件的系统方法》、《DevOps Master 白皮书-企业DevOps的成功之路》，《Effective DevOps》，三月份完成了DOF，集中精力每天下班后从7点看书到晚9点半，把《持续交付：发布可靠软件的系统方法》刷了2遍，每一遍都很有收获。
DevOps 实践——凤凰沙盘 DevOps 实践是比较有意思的，我们分成两组PK，挑选心仪的角色，想着凤凰项目书里的境界，心想今天稳了（后来才发现处处充满惊喜，突如其来的调整组织，调整业务规则，生产环境不断出现的事故，一线的故障，HR部门跑路）。 九点小伙伴们基本就位，现场太热闹了，天南海北的都有（角色覆盖咨询师，顾问，开发，测试，产品，PMO，架构师，运维工程师，业务分析人员）
tips：多元化的团队，增加不同的观点和能力，去挑战、 创新、反馈，吸纳具有更广泛的个人背景和文化的人才来提高团队的多元性，显著的益处是：能够带来更多的经验与观点，凤凰沙盘真是有意思！
教练把我们分成2组，乘风破浪组和凤凰传奇组，我所在的正是乘风破浪组。 接到的第一个任务：姓名/城市/职业/为什么要参加DevOps Master 培训。 三分钟基本上大家轻车熟路完成任务，只要需求满足INVEST原则，那业务能力杠杠的，不愧都是有思想觉悟的潜力股，没有想到认识的都是大佬，我新认识了两个朋友：周同学（后续小康童鞋是我们的CFO）和吕同学（我们在第三轮休息的时候说，让CFO去把小雪他们组的需求卡片偷掉，解放凤凰传奇996的兄弟姐妹们，最后觉得让他们007吧）。
Tips：用户故事的INVEST原则，有助于确定验收标准。
第二个任务：
打破部门墙姜还是老地辣，光是从名字：李聃就超级霸气，老子(李聃)说啥都对，老李从第一个任务项里面很快就发现”部门强”的存在，大家基本就和身边的人进行商业互吹，一个桌挪个位置的都不想，可见平时996把大家给累的，能躺着不坐着，能坐着绝不站着，嘿嘿，老李用了一个四两拨千斤的骚操作，让大家伙活络活络，按照身高由高到低左边高右边低排序，大家伙正磨蹭的时候，老李临时改变需求，排序规则按照右边高左边低的业务逻辑排序，大家伙唰唰的找到了自己的定位，然后从0开始报数，单双数分组。
Tips：解决你的问题的最佳策略是:在一开始找到一个共同的目标，并让你的团队开始朝着这个目标努力，以增加合作。
第三个任务：
取组名，开张营业我们搞事情要名正言顺呀，分组完成接下来第一件事肯定是取一个响当当的名字哇，嘿嘿，深知在座的各位肯定是公司中的领导，我们打工人默默的板砖：我主动提出一个：超能陆战队，紧接着小伙伴提议乘风破浪，领导们一致投票乘风破浪，我妥妥的风向标，team润滑剂，第一时间把组名搞定。
Tips：通过互相支持和多人协同来达成特定结果，业务价值通过协作实现，DevOps的业务价值是通过团队间的合作来实现的。
经过三个任务破冰结束，接下来进行day01的《凤凰项目沙盘》四轮实践，开启斗智斗勇的一天。
简单复盘一下四轮的情况：
第一轮：
乘风破浪战队完成项目相关的任务项1个，解决2个紧急生产事故，1个任务项未完成（库存浪费），股价和收入都未达标。
做的很好的点：测试驱动开发（TDD），零售部门提出需求后，我们就一起和测试确定验收标准，然后一起找出关联任务项，每完成一个打一个勾（类似于自动化验收测试），通过了后我们才开始下一个新的任务项（单件流）。 可以做得更好的：业务零售部门 & CEO & CISO & IT VP 需求优先级确认规则不清晰，后端资源被动等待（资源浪费）。
中午饭时间：小伙伴们觉得这些业务零售部门、CEO、CISO、IT、VP家伙不给力，需求优先级都排不好，要不让他们下岗吧，我们坚决的否定了。
Tips：DevOps环境中不存在追责。若team成员不承担责任，不要强迫他们
第二轮：
乘风破浪战队完成项目相关的任务项1个，解决3个紧急生产事故。股价和收入都达标。
做得好的：我们噼里啪啦画了个看板（只看不用的那种）可以做得更好的：把看板用起来，可视化，单件流，等小技巧用起来。所以李聃教练恨铁不成钢：硬生生把我们team名为：乘风破“凉”！CEO对我们的表现很生气啊。 第二轮过程中我建议我们去看看隔壁组的小伙伴的看板，这样有助于在脑海里有一个映象后就去试试我们的看板和价值流。凤凰传奇小组可真能，直接把CFO和IT、VP放假了，对CFO紧急插的单say no，全心全意关注公司目标，提高股价和交付项目。学到的经验是团队要面对用户干活，而不是面对老板（那个工资最高的人）干活。
Tips：零售部门负责人需要从产品备忘录和IT服务计划中确定任务优先级。起到打远光灯的作用，引导team朝共同的目标努力。
第三轮：
乘风破浪战队完成项目相关的任务项2个，解决4个紧急生产事故，股价和收入超额完成。
做得好的：在老师的墙裂建议下，可视化我们的流程，规则，我们敢为先的把看板搬上了墙，一是可视化效果很好，大家可以聚集在看板前进行讨论，二是相比弯腰在地上工作相对舒适，其优势是不用贴胶带。我们把产品待办清单放入可视化看板，按需求优先级统一规则，ROI最高的优先排序，这样决策只需做一次（回答why），后续关注如何做（how）。容量方面大部分容量预留给项目（计划内），生产环境问题预留容量（计划外），当CFO和CISO紧急事件加入时，我们也可以从容淡定应对VIP客户，我们给自己留了退路，紧急通道有且仅能有一个事项。
可以做得更好的：团队内部的培训，团队外的经验吸取可以更频繁。
Tips：DevOps中最重要的工作在于构建从开发部门到运维部门的上游流程，尤其是针对单一部署流水线。
第四轮：
乘风破浪战队完成项目相关的任务项2个，解决7个紧急生产事故。股价超额完成，收入未达标。
做得好的：
大家高度一致的聚焦凤凰项目还未完成的两个需求，整个团队同频共振的那种心流太奇妙了。当为了一个共同的目标而发力的时候，大家自发的为项目贡献力量，当工作出现瓶颈时，大家主动的进行任务协调，当出现紧急插单时，大家尽早的一起拉通信息，没有人喜欢不知情。
可以做得更好的：安全相关的工作不一定非得从开发团队入手，可以用业务层面进行干预。
Tips：重新检查流程，明确哪些事项能够简化，确立每个流程的角色、责任与归属权，明确权衡生产率与风险的有效方法，促进渐进式变化，并营造一个安全的环境尝试和实验。
总结：
感谢老师带领我们乘风破浪的兄弟姐妹队玩了一整天凤凰项目沙盘游戏，到最后大家精疲力尽，但也收获颇丰。看着凤凰项目的30美元股价与10万美元营收，最后涨到了53美元股价与27万美元营收，心中无比骄傲。
凤凰项目沙盘游戏核心是业务部门、IT部门等多种角色通力合作与配合。最终完成凤凰项目在市场层面取得成功（股价与营收）。凤凰项目沙盘游戏让我们在游戏过程更了解做IT是为了实现业务价值，从CFO确立市场目标，业务部门确认业务需求、IT部门开发、测试、部署、实施、排障与运维形成完业务整价值流动。
相信，随着数字经济的不断发展，未来的世界一定是敏捷的世界，而devops凤凰沙盘项目对我，不只是技术的提升，而是思维方式的一种转变与升级。
DevOps理论知识 【DevOps Master凤凰沙盘的学习体验】学会了PDCA + KAIZEN可以小伙伴们重新定义PDCA了（plan + delay + cancel + apologize 更牛的还有可以是agagin），某科技公司对PDCA进行改造，PDF模型=plan + delay + 复盘，东西方文化结合，太能了。 每个企业遇到的情况不同，没有统一的模板去实施devops，也衷心的希望devops master们把这两天学到的宝贵经验，带回企业去。从最小切入点开始，你的鼓励，团队就可能迈出了小小的一步，这一步是DevOps进步的一大步。
DevOps Master凤凰沙盘的学习体验
文章图片

大家如果想要资料可以给我留言，关注我。

    推荐阅读


    上一篇：Apache ShardingSphere Agent 可观察性实用指南

    下一篇：浅析MySQL恶意服务器读取文件原理