DH3G游戏资讯网

突破四大要素 飞算 SoFlu 助力企业实现 DevOps 落地

发表于:2024-12-22 作者:创始人
编辑最后更新 2024年12月22日,自 2008 年在多伦多敏捷会议上,Petrick Debois 提出"DevOps"一词以来。经过十三年的发展,DevOps 已经被视为企业发展的关键, 绝大多数的组织都正在引入 DevOps 以应

自 2008 年在多伦多敏捷会议上,Petrick Debois 提出"DevOps"一词以来。经过十三年的发展,DevOps 已经被视为企业发展的关键, 绝大多数的组织都正在引入 DevOps 以应对更复杂的开发需求和环境。但如何才能成功实践 DevOps 至今依旧是待解问题。

Puppet 发布的 2021 年度 DevOps 状况调查报告指出,83% 的 IT 决策者表明他们的组织正在实施 DevOps 实践; 与此同时, 绝大多数组织仍然停留在 DevOps 演变的中期阶段。企业在落地 DevOps 实践时, 仍面临许多挑战, 因此, 业界也在多年的实践之中, 总结出一些关键要素, 来帮助推动 DevOps 实践。

DevOps 关键要素

目前 DevOps 实践中的一些关键要素注重文化层面, 由 DevOps 标准核心编写专家总结出 4 个关键要素。

一个关键因素是 IT 部门和业务部门的目标要对齐。

IT 部门和业务部门常常有矛盾。如业务部门对 IT 部门的不满来自四个方面, 一是 IT 人员与业务部门沟通补偿, 缺乏系统性的运营管理思维, 导致业务部门认为双方愿景无法匹配; 二是 IT 部门聚焦过程而非结果; 三是 IT 部门总是在解决自己的问题, 忽略了产出, 同时会不断有新的问题出现; 四是对于业务部门来说, 整个 IT 内部像是一个黑盒子, 因为管理部门通常会说 IT 部门是无法控制的黑盒, 专注于技术, 缺乏沟通, 同时 IT 人员及各种服务设备越来越贵, 功能不透明等等都让业务部门认为难以沟通。

反过来, 为什么 IT 部门做了很多事情但是业务部门不买账?IT 部门对业务部门也有许多不满, 他们会认为业务部门的许多需求不够清醒, 从开发初期到上线需求一直在改; 另外业务只提出高优先级, 常常没有低优先级, 难以分出哪个需求是最高优先; 不知道业务指标和收益, 不清楚开发出来的功能有多大效果。

因此, 目标对齐非常重要,IT 部门和业务部门之间要做好充分的联合, 聚焦客户价值, 关注客户的实际需求、满意度等等。

第二个关键要素是人员和文化。

传统的开发模式下一般是项目制, 同时把各个项目分割成不同的开发阶段, 包括需求、定义、设计、编码、单测等等, 同时使用里程碑方式, 严格定义开发阶段的输出, 达不到相应输出则不能展开下一阶段工作。这种工作模式将开发阶段定义成黑盒, 希望每个人阶段的技术人员只关注自己阶段的工作, 好处是可以让不同角色的人员专注本质工作, 提高阶段效率; 坏处是出现问题可能会互相推诿, 并且由于每个开发阶段的信息相对封闭, 会造成大面积的理解偏差。

Puppet 发布的 2021 年度 DevOps 状况调查报告同时还指出, 绝大多数组织仍然停留在 DevOps 演变的中期阶段, 其中文化问题是 DevOps 取得成功的最大障碍。

调查结果显示, 只有 18% 的受访者拥有高效的 DevOps 团队,4% 处于低功能状态, 大多数 (78%) 处于中间状态。虽然处于中间状态的组织表示, 他们正在建立 DevOps 文化。但 Puppet field CTO Nigel Kersten 认为,"仍然存在组织对变革的抵制, 这是一个真正的问题。而且人们真的没有看到他们实际上试图通过 DevOps 实现的实际价值。"中层最常见的文化阻碍因素包括有: 不鼓励风险的文化 (21%)、不明确的责任 (20%)、不优先考虑快速流程优化 (18%) 和不充分的反馈循环 (17%)。

因此做好 DevOps 的文化工作, 让团队熟悉 DevOps 的流程及相关操作规范至关重要。

第三个要素是流程。

对于一个项目来说, 在立项之初, 大家对项目的关注度和期望很高, 因此刚开始时有较高的能见度, 但在执行过程中, 能见度会越来越低。所以在敏捷开发中会采用迭代开发方式, 项目全程可见度高, 并且不断与客户探讨相关需求, 根据反馈做改进, 这样达到的最终结果是业务价值持续稳步上升, 同时风险也被很好地控制。

第四个要素是平台。

在挑选平台时, 往往要注意的点通常包括自动化、可视化、自主服务。自动化需要做到标准化; 同时通过平台达到自动服务也非常关键; 还有可视化, 包括端到端流水线的可视化, 度量可视化, 业务数据、研发效能、质量、速度、满意度等等皆可通过可视化方式改进。

关于自动化, 有三个关键前提。第一是标准化, 需要有相应流程和规范的梳理, 只有形成流程和规范的标准, 后续的相关维护与功能拓展才能使用版本化的管理方式。第二方面, 对于平台化建设的自助服务, 其中最关键的是打造一个尽可能傻瓜式的自助服务平台。第三方面涉及平台度量的可视化, 包括合规的展示, 安全和开源合规也尤为重要, 此外关于可靠性的展示也非常重要。

关于第四要素平台的一些特质, 飞算云智总裁陈定玮在近期的访谈中也提到, 飞算 SoFlu 全自动软件工程平台上通过制定系列标准, 来规范软件工程全流程开发管理。飞算 SoFlu 全自动软件工程平台团队将前沿大厂使用的开发规范结合实际遇到的问题处理方式后, 从效率、安全等多方面考虑, 制定了自己的代码规范。比如, 限定每行代码的写法、有些地方不允许 SQL 拼接、Join 不允许超过三次等。除了规范, 所有的代码还必须接受严格检测, 确定没问题后才会被提交到代码仓库。同理, 所有组件也必须经过代码质量管理工具扫描无误后才让用户使用。现在, 飞算 SoFlu 全自动软件工程平台的质量管理平台上已经有一千多条标准, 而新的规则也在不断被加入其中。

企业的 DevOps 实践

在这些关键要素的基础之上, 企业想要完整落地 DevOps 实践, 首先需要确立从项目到产品的研发模式。第二借助 DevOps 平台, 通过那些服务属性的功能, 支持产品开发与业务上线, 同时建立相应的防御和审批措施。第三在部署方面, 新的部署方式可能逐渐会有运维人员支持做上线, 演变成平台全流程支持, 随着平台建设越来越完善, 能够提供足够多的监控和审计功能, 当项目制演变成产品制之后, 产品开发团队就完全可以做到自助式流程变更甚至代码提交等等。第四, 要非常注重用户体验, 包括在做 DevOps 自动化部署平台时, 也要关注运维相关体验, 从开发到测试以及最后维护环节所有使用人员的体验。

对于企业引入 DevOps 流程, 在平台之上实现敏捷开发, 陈定玮也提出了自己的看法, 在他看来, 平台如果不能真正帮助企业降本增效, 反而是害了企业。因此, 他也一直强调自己是交钥匙工程,"未来企业不需要继续依托我们进行维护和迭代, 并且在部署层面可以节省企业很多资源。平台分布式、可弹性扩缩容的设计理念相当于帮企业做了中长期的规划, 只需要适时增加硬件资源即可帮助业务快速上升, 无需对结构进行大的调整。"

未来, 随着 DevOps 平台的不断发展与完善, 企业在落地 DevOps 实践时, 将有更多可依靠的标准, 趁手的工具, 以及专业的指导, 来达成愈发成熟的实践。

2022-05-06 14:57:42
0