32、企业转型:DevOps 驱动的成功之路

企业转型:DevOps 驱动的成功之路

1. 寻求帮助的重要性

在企业转型过程中,很多人对咨询顾问存在负面看法,这往往源于一些糟糕的经历。比如曾有客户习惯瀑布式开发方法,在引入 Scrum 和 CI/CD 并成功实践两年后,管理层又聘请昂贵的咨询公司来介绍同样的内容,这无疑损害了咨询顾问的声誉。

然而,就像学习新运动时,仅购买装备和观看视频是不够的,还需要加入俱乐部或找教练指导。因为运动不仅关乎知识和工具,更在于技能的培养。同理,企业构建新技能和能力时,向更有经验的人寻求帮助并非羞耻之事。从节省的时间和精力来看,这种帮助的成本可能很低,更不用说避免失败所带来的损失了。

2. 从“为什么”开始转型

2.1 明确愿景和紧迫性

转型要成功,清晰的愿景和紧迫感至关重要。愿景应精确、有吸引力、简洁,并能激励人们追随。可以借鉴黄金圈法则,从内到外进行沟通:
- 为什么(WHY) :企业进行转型的原因,赋予转型目的和紧迫感。例如大众集团 2019 年的“goTOzero”使命声明,聚焦气候变化、资源、空气质量和环境合规四个主要领域,计划到 2050 年实现资产负债表二氧化碳中和,到 2025 年将车队碳足迹在 2015 年基础上减少 30%。这清晰解释了转型原因,确立了紧迫性,符合其让世界成为移动、可持续之地的愿景。梅赛德斯 - 奔驰在 2019 年的“Ambition 2039”声明中也表明,未来 20 年将实现汽车车队和生产的碳中和。
- 怎么做(HOW) :在转型过程中如何取得成功。
- 做什么(WHAT) :实际要转型的内容。

2.2 目的驱动的使命

愿景的力量不容小觑。以汽车制造商从内燃机汽车向电动汽车转型为例,这一过程会面临阻力,人们会担心失去工作中的权力。因此,需要清晰的愿景并沟通“为什么”。同样,将产品公司转变为软件或服务公司,或从瀑布式组织转变为 DevOps 组织时,如果不能描绘出理想的未来图景并解释转型原因,人们会对变革产生恐惧和抵触。

3. 建立工程文化

3.1 文化的内涵

有目的驱动的愿景有助于在转型过程中建立工程文化,这是一种包容、安全的组织文化,注重人才培养,以共享和平等为驱动。在这种文化中,人们在感觉有问题时能安全地表达意见,能无畏地进行实验和创新,无论出身、性别或宗教如何,都能感受到欢迎和安全。

3.2 文化的改变

组织文化是一套共享的假设,指导着组织内的行为,因此改变它并不容易。仅仅创建带有价值观和使命声明的幻灯片可能会影响文化,但不一定能达到管理层预期的效果。作为工程师,应意识到组织文化与自己息息相关,因为文化是系统中每个人的假设和行为的结果,每个人都可以改变它。当看到问题时,工程师应勇敢表达,并开始做正确的事、讲述正确的故事。

3.3 文化的体现

通过一些具有深刻含义的小语录和原则,可以将文化融入企业行为中,这些语录和原则容易记忆,能鼓励人们做正确的事。常见的有:
- 先行动后请求原谅 :鼓励人们做正确的事,即使违反当前规则或流程。
- 谁构建谁运行 :建立对所构建事物的端到端责任和所有权。
- 尽早失败、快速失败、经常失败(或快速失败,继续前进) :尝试尽早和快速失败,而不是追求完美。
- 拥抱失败 :鼓励人们进行实验和冒险,确保从失败中无责学习,承担责任,不指责他人。
- 合作而非竞争 :促进跨组织边界以及与客户和合作伙伴的协作。
- 去修复 :鼓励人们承担责任并修复问题,而不仅仅是抱怨,同时要确保创新不被抑制,让人们有能力真正解决他们抱怨的问题。
- 将服务器视为牲畜而非宠物 :鼓励自动化一切。
- 如果痛苦,就多做 :激励人们练习困难的事情,以积累技能,常用于应用程序的发布或测试。

4. 数据驱动的转型

4.1 衡量关键指标

转型要成功,关键在于衡量正确的指标,并证明转型比旧系统能带来更好的结果。在开始时,应定义指标并收集数据,优化有约束的方面,避免基于假设进行优化而浪费资源或产生负面影响。例如,在没有证明操作会减慢系统速度或缓存数据能提高多少速度的情况下,为应用程序添加缓存,可能会增加复杂性并引入错误。

4.2 约束理论

约束理论(TOC)基于系统理论,认为如果没有限制约束,系统的吞吐量将是无限的。该理论试图在当前约束条件下最大化系统吞吐量,或通过减少约束来优化系统。以高速公路为例,假设有一条五车道的高速公路,但有两个施工点限制了两条车道的通行能力。交通在一定吞吐量内可以通过这些约束,但如果车辆过多,就会相互影响并导致交通堵塞。为了实现最大流量,必须将交通限制在最大约束的容量范围内。同理,在价值流中,优化非最大约束不会带来任何改善。

4.3 消除瓶颈的步骤

TOC 提供了消除约束的五个重点步骤:
1. 识别 :确定限制当前吞吐量的约束。
2. 利用 :对约束的吞吐量进行改进。
3. 同步 :审查并协调系统中的其他活动,确保它们以最佳方式支持约束。
4. 提升 :尝试消除约束,解决问题的根本原因。
5. 重复 :通过识别下一个限制当前吞吐量的约束,持续改进系统。

系统地消除工作流程中的瓶颈是 DevOps 转型成功的关键。

5. DevOps:持续改进的旅程

5.1 DevOps 的本质

DevOps 是通过消除瓶颈不断提升软件交付性能的旅程。微软在 DevOps 转型启动时展示了不同地区赛车进站的视频,从 1950 年印第安纳波利斯的 67 秒到 2013 年墨尔本的约 2.96 秒,这很好地比喻了 DevOps 通过自动化和优化流程持续改进性能的过程。

DevOps 是人员、流程和产品的结合,旨在为最终用户实现价值的持续交付。它是一种融合研究、开发、协作、学习和所有权的工程文化,只有全面实施各个方面才能发挥作用,不能只选择其中一个方面而忽略其他方面。

5.2 优化价值流对齐的团队

在转型中,应关注价值流对齐的团队。DevOps 之旅应从这些团队开始,优化一切以使其能够交付价值,这将自然形成以开发者为先的思维。通过数据驱动的转型和消除瓶颈来优化价值,像平台团队或支持团队等拓扑结构会自然出现,无需提前规划。一个成功的 DevOps 组织应该是一个自我改进的系统。

5.3 数据驱动的 DevOps 转型阶段

数据驱动的 DevOps 转型有三个主要阶段:
| 阶段 | 详情 |
| — | — |
| 指标 | 开始定义指标并收集数据。 |
| 工具决策 | 需做出一些基本的工具决策,如假设 GitHub 为 DevOps 平台,还需考虑云使用和与当前治理流程的对齐。 |
| 人员、流程和文化 | 精心挑选试点团队,将他们带到新平台,转变工作方式为精益管理和更高程度的协作。教导并使他们采用自动化和基于主干开发等 DevOps 工程实践,让他们有信心频繁发布。指标应迅速改善,这些快速胜利能保持大家的积极性。 |
| 扩展和优化 | 试点团队成功后,可通过创建更多在新平台上使用新流程和工具的团队来进行扩展。此时也开始优化更多能力,如软件架构和精益产品管理技术。一次处理一个瓶颈,始终观察指标是否符合预期结果。由于 DevOps 是旅程而非目标,此阶段基本不会结束,随着水平提高,优化结果会越来越小。 |
| DevOps 愿景 | 整个转型过程的核心是强大的愿景,解释“为什么”并建立紧迫感。确保制定良好的沟通和变革管理策略,应对变革中的阻力,沟通转型过程的“为什么”“怎么做”“做什么”以及沿途收集的成功故事,激励大家前进。 |

6. 总结

如今,企业要保持竞争力,不能仅解决客户问题,还需提供让客户满意的产品和服务,能够快速响应市场变化。这使得每个企业都成为软件公司,如果不能转型,可能在几年内就会被淘汰。

虽然很多转型会失败,但也有许多成功案例,证明大企业或受严格监管环境下的公司也能成功转型并采用 DevOps。GitHub 作为市场上优秀的产品,受到全球超过 7300 万开发者、所有大型开源社区和超过 84%的财富 500 强公司的喜爱,具有培训少、入职快和开发者满意度高的优势,有助于吸引和留住人才。同时,开源社区为应用程序、工具和管道提供构建模块,也为流程模板提供支持。利用社区的力量可以加速转型,企业也可以通过贡献或赞助依赖的项目来回馈社区。

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([开始转型]):::startend --> B{明确愿景和紧迫性}:::decision
    B -->|明确 WHY、HOW、WHAT| C(建立工程文化):::process
    C --> D(数据驱动转型):::process
    D --> E(消除瓶颈):::process
    E --> F(优化团队):::process
    F --> G(分阶段推进转型):::process
    G --> H([持续改进]):::startend

通过以上步骤和方法,企业能够在 DevOps 的驱动下实现成功转型,不断提升竞争力,适应市场的变化和发展。在转型过程中,要始终牢记数据驱动、持续改进的原则,关注团队的培养和文化的建设,以确保转型的顺利进行和长期成功。

7. 转型中的技术与操作要点

7.1 代码与版本管理

  • 代码迁移 :将代码迁移到 GitHub 时,有多种方式。可以使用 GitHub Importer 迁移代码,也可借助 GitHub Enterprise Importer 进行更复杂的迁移。对于不同的版本控制系统,如 Mercurial、Subversion 等,都有相应的迁移策略。
  • 分支管理 :避免复杂分支,推荐采用如 GitHub flow、trunk-based development(TBD)等简单高效的分支模型。例如,trunk-based development 以主干为核心,开发人员直接在主干上进行开发,减少分支合并的复杂性。
  • 版本控制 :采用语义化版本控制,如 major.minor.patch 的格式,清晰标识版本的更新情况。

7.2 自动化与持续集成/持续交付(CI/CD)

  • 自动化操作 :通过 GitHub Actions 实现自动化部署,包括应用程序和容器的部署。例如,部署应用程序时,可按以下步骤操作:
    1. 配置 GitHub Actions 工作流文件。
    2. 指定部署目标,如 AWS ECS、Azure App Service 等。
    3. 编写脚本实现代码部署。
  • CI/CD 流程 :遵循 CI/CD 原则,实现代码的持续集成和持续交付。具体流程如下:
    1. 开发人员提交代码到版本控制系统。
    2. CI 工具自动触发构建和测试流程。
    3. 测试通过后,代码自动部署到预生产环境进行验证。
    4. 验证通过后,代码部署到生产环境。

7.3 安全与合规

  • 安全措施 :采用多种安全措施保障系统安全,如:
    • 代码扫描:使用 CodeQL 等工具进行代码扫描,检测潜在的安全漏洞。
    • 容器安全分析:对容器进行扫描,分析容器的安全性。
    • 安全审计:通过 Audit API 对系统进行安全审计。
  • 合规标准 :企业需满足各种合规标准,如 GAMP、ISO26262 等。对于低保真度迁移,可通过特定方法实现合规。

7.4 测试与质量保障

  • 测试策略 :采用多种测试策略,包括单元测试、集成测试、性能测试等。例如,在进行测试时,可按以下步骤进行:
    1. 编写测试用例,覆盖不同的功能场景。
    2. 使用自动化测试工具执行测试用例。
    3. 分析测试结果,及时修复发现的问题。
  • 测试优化 :处理不稳定测试(flaky tests),可通过优化测试环境、增加重试机制等方法解决。

8. 团队协作与沟通

8.1 团队结构与角色

  • 团队类型 :采用不同的团队类型,如价值流对齐的团队、平台团队、支持团队等。这些团队相互协作,共同推动企业转型。
  • 角色定义 :明确团队成员的角色和职责,如开发人员、测试人员、运维人员等。每个角色在转型过程中都发挥着重要作用。

8.2 协作工具与方法

  • 工具使用 :利用 GitHub 提供的各种工具进行协作,如 GitHub Issues 进行任务管理、GitHub Discussions 进行交流讨论等。
  • 协作方法 :采用敏捷开发方法,如 Scrum、Kanban 等,提高团队协作效率。例如,在 Scrum 中,通过每日站会、迭代计划会议等方式,确保团队成员之间的沟通和协作。

8.3 沟通策略

  • 沟通渠道 :建立多种沟通渠道,包括面对面会议、远程会议、即时通讯工具等。确保团队成员之间能够及时、有效地沟通。
  • 沟通文化 :营造开放、透明的沟通文化,鼓励团队成员分享想法和经验。

9. 案例分析与实践经验

9.1 成功案例

以某企业为例,该企业通过采用 DevOps 方法,成功实现了从传统开发模式向敏捷开发模式的转型。具体措施包括:
- 引入 Scrum 和 CI/CD 流程,提高开发效率。
- 利用 GitHub 作为开发平台,实现代码的集中管理和自动化部署。
- 建立工程文化,鼓励团队成员创新和协作。

通过这些措施,该企业的产品交付周期缩短,质量得到显著提升。

9.2 实践经验总结

  • 数据驱动 :始终以数据为导向,通过收集和分析数据,优化转型过程。
  • 团队建设 :注重团队建设,培养团队成员的技能和能力,提高团队的协作效率。
  • 持续改进 :将持续改进作为转型的核心,不断优化流程和方法。

10. 未来展望与建议

10.1 未来趋势

随着技术的不断发展,DevOps 将朝着更加智能化、自动化的方向发展。例如,人工智能和机器学习将在 DevOps 中得到更广泛的应用,实现自动化的故障诊断和修复。

10.2 建议

  • 持续学习 :企业和团队成员应持续学习新技术、新方法,适应不断变化的市场环境。
  • 创新实践 :鼓励创新实践,尝试新的技术和方法,推动企业转型。
  • 保持开放 :保持开放的心态,与行业内的其他企业和团队进行交流和合作,分享经验和资源。
graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([开始转型]):::startend --> B(技术准备):::process
    B --> C(团队协作):::process
    C --> D(安全合规):::process
    D --> E(测试优化):::process
    E --> F(持续改进):::process
    F --> G([转型成功]):::startend

总之,企业转型是一个复杂而长期的过程,需要企业从多个方面进行努力。通过采用 DevOps 方法,以数据为驱动,注重团队建设和文化培养,不断优化流程和方法,企业能够实现成功转型,在激烈的市场竞争中立于不败之地。

基于可靠性评估序贯蒙特卡洛模拟法的配电网可靠性评估研究(Matlab代码实现)内容概要:本文围绕“基于可靠性评估序贯蒙特卡洛模拟法的配电网可靠性评估研究”,介绍了利用Matlab代码实现配电网可靠性的仿真分析方法。重点采用序贯蒙特卡洛模拟法对配电网进行长时间段的状态抽样与统计,通过模拟系统元件的故障与修复过程,评估配电网的关键可靠性指标,如系统停电频率、停电持续时间、负荷点可靠性等。该方法能够有效处理复杂网络结构与设备时序特性,提升评估精度,适用于含分布式电源、电动汽车等新型负荷接入的现代配电网。文中提供了完整的Matlab实现代码与案例分析,便于复现和扩展应用。; 适合人群:具备电力系统基础知识和Matlab编程能力的高校研究生、科研人员及电力行业技术人员,尤其适合从事配电网规划、运行与可靠性分析相关工作的人员; 使用场景及目标:①掌握序贯蒙特卡洛模拟法在电力系统可靠性评估中的基本原理与实现流程;②学习如何通过Matlab构建配电网仿真模型并进行状态转移模拟;③应用于含新能源接入的复杂配电网可靠性定量评估与优化设计; 阅读建议:建议结合文中提供的Matlab代码逐段调试运行,理解状态抽样、故障判断、修复逻辑及指标统计的具体实现方式,同时可扩展至不同网络结构或加入更多不确定性因素进行深化研究。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符  | 博主筛选后可见
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值