云原生转型:策略、实践与未来展望
1. 避免重复造轮子
在非核心业务需求方面,应优先考虑购买解决方案,而非定制开发完美工具。虽然曾经为确保本地和云端环境的兼容性进行大量定制开发,导致进度放缓,但这一过程也带来了宝贵的经验。如今,即便购买托管的 Kubernetes 服务,也能清楚其底层原理。
2. 云城发展现状
从最初的一个集群和单一电商应用,已发展到在全球五个地点部署,部分地点拥有多个生产集群,均采用 Kubernetes 技术。每个地点还配备 Kafka 集群以及监控、可观测性工具和 CI/CD 流程所需的基础设施。
以下是当前的一些关键数据:
| 项目 | 详情 |
| ---- | ---- |
| 内部工程师 | 300 多名 |
| Bitbucket 账户 | 2000 多个 |
| CI/CD 系统每月构建次数 | 约 100,000 次 |
| 每周中央日志基础设施收集的指标数据量 | 25 TB |
| 数据湖大小 | 超过 750 TB |
| Kafka 消息数量 | 超过 1000 万条且持续增长 |
| Kubernetes 容器数量 | 近 4000 个 |
| Bitbucket 代码库行数 | 超过 1 亿行 |
| AWS 平台工具使用数量 | 28 个 |
这些数据表明,云原生转型并非简单的技术安装,而是技术、流程和文化协同发展的过程。如果这三者不能协同演进,转型将面临诸多挑战。
3. 团队发展历程
四年前,工程团队规模小且分散,成员交流较少。如今,公司的工程日活动参与人数达 600 人,涵盖工程师、服务经理、运维人员、架构师和业务产品负责人等。
4. 云原生转型的关键模式
- 远程团队管理 :若团队分布在不同地点,应定期组织面对面的团队活动,并建立高效的沟通渠道。
- 持续教育 :优先为团队提供持续学习云原生知识和技能的机会。
- 业务与技术协作 :业务团队和技术团队需紧密合作,建立有效的客户反馈循环,以推动产品改进。
以下是这些模式的简要说明:
| 模式 | 说明 |
| ---- | ---- |
| 远程团队管理 | 定期组织面对面活动,建立高效沟通渠道 |
| 持续教育 | 提供云原生知识和技能学习机会 |
| 业务与技术协作 | 建立客户反馈循环,推动产品改进 |
5. WealthGrid 云原生转型案例
WealthGrid 在云原生转型过程中经历了三次尝试。前两次尝试均以失败告终,第一次未将转型作为重点项目,创造力不足;第二次虽有高层支持,但管理和团队结构未适应新技术,导致资源分配失衡。
第三次尝试中,公司采用动态策略,逐步提高投入,组建核心团队和平台团队,通过探索性实验和概念验证,成功构建了云原生平台。以下是转型过程的 mermaid 流程图:
graph LR
A[第一次尝试] --> B[未重视转型,创造力低]
B --> C[转型失败]
A --> D[第二次尝试]
D --> E[高层支持,但管理和结构未适应]
E --> F[资源分配失衡,转型失败]
D --> G[第三次尝试]
G --> H[采用动态策略,组建核心团队和平台团队]
H --> I[探索性实验和概念验证]
I --> J[构建云原生平台]
J --> K[转型成功]
转型成功后,公司实现了云原生工作模式,在保证交付效率的同时,持续投入创新和研究。团队根据不同任务采用不同的管理方式,以平衡效率和创新。
6. 云原生转型的未来挑战与应对
云原生转型的关键在于平衡效率和创新。公司可根据实际情况调整资源分配,在不同阶段灵活管理团队。例如,在进行大型重构或新产品开发时,可将部分团队成员投入创新任务,待任务完成后再重新平衡。
云原生不仅带来速度、规模和利润等优势,更重要的是帮助企业构建适应变化的组织能力。虽然转型过程需要付出努力,但在当前竞争激烈的市场环境下,云原生转型势在必行,且风险已降至较低水平。
7. 云原生模式库
为了持续分享和扩展云原生模式语言,可访问 www.CNpatterns.org 。以下是部分云原生模式的简要介绍:
| 模式名称 | 说明 |
| ---- | ---- |
| A/B 测试 | 在真实客户使用条件下比较多个版本,获取性能数据 |
| 敏捷开发 | 在开发周期中平衡效率和创新 |
| 架构图绘制 | 用图表简化系统架构说明,避免误解 |
| 自动化基础设施 | 自动化大部分操作任务,提高开发速度 |
| 自动化测试 | 将测试责任转移到自动化框架,提高产品质量 |
| 避免重复造轮子 | 非核心业务需求优先购买解决方案 |
| 重大决策 | 信息充足时,果断推进云迁移解决方案 |
| 无责调查 | 问题发生时,关注事件本身,促进学习 |
| 构建 - 运行团队 | 开发团队对服务全生命周期负责 |
| 业务案例评估 | 转型前评估必要性和投资回报率 |
| 共址团队协作 | 面对面工作促进团队关系和创新 |
| 通过 API 通信 | 分布式系统中微服务通过稳定 API 通信 |
| 通过部落交流 | 组建相似技能团队交流思想 |
| 容器化应用 | 应用打包后可在任何平台运行 |
| 持续交付 | 保持短周期开发,快速响应客户需求 |
| 持续部署 | 自动将代码部署到生产环境 |
| 持续集成 | 频繁集成小改动,提高代码质量 |
| 核心团队 | 负责探索和实施转型路径 |
| 数据驱动决策 | 收集和分析数据,支持客观决策 |
云原生转型:策略、实践与未来展望
8. 云原生模式库(续)
除了上半部分介绍的云原生模式,还有许多其他重要模式,以下是详细列表:
| 模式名称 | 说明 |
| ---- | ---- |
| 延迟自动化 | 问题完全解决且手动运行几次后再进行自动化 |
| 演示应用程序 | 为新团队提供云原生应用开发的教育起点 |
| 激进创新的设计思维 | 用于头脑风暴解决方案并筛选最佳方案 |
| 指定策略师 | 任命人员负责组织的态势感知 |
| 开发者入门包 | 提供资源帮助新团队快速自信地加入云原生系统 |
| 分布式系统 | 软件构建为独立、松耦合服务,系统具有高扩展性 |
| 动态调度 | 编排器(如 Kubernetes)管理微服务部署 |
| 动态策略 | 市场环境变化时及时调整策略 |
| 高管承诺 | 大规模项目需高管团队的有力支持 |
| 退出策略优于供应商锁定 | 选择供应商时考虑替代方案和切换成本 |
| 探索性实验 | 面对复杂问题时通过小实验评估方案 |
| 全面生产就绪 | 平台具备 CI/CD、安全等关键特性后再上线 |
| 逐步引入 | 新平台上线前分批次培训团队并收集反馈 |
| 逐步提高风险 | 不确定环境下逐步增加学习和信息收集投入 |
| 内部宣传 | 从一开始就在公司内宣传转型信息以获得支持 |
| 业务参与 | 业务和技术团队协作建立客户反馈循环 |
| 精益优化 | 稳定系统注重持续改进交付和维护流程 |
| 学习循环 | 在交付过程中收集反馈,以客户为中心开发产品 |
| 学习型组织 | 善于获取信息、创造洞察和传递知识的组织 |
| 最后进行迁移 | 云原生转型后期可迁移部分完整系统 |
| 创新管理 | 创新团队需自由实验,允许失败 |
| 效率管理 | 稳定工作团队注重高质量和高效率 |
| 衡量关键指标 | 正确衡量工作以引导正确目标 |
| 微服务架构 | 构建模块化服务以降低团队协调成本 |
| MVP(平台) | 实验后构建简单但功能完整的生产平台 |
| CI/CD 中无长时间测试 | 非关键长时间测试在后台运行,不阻塞交付 |
| 无悔行动 | 小而快的行动增加知识、降低风险 |
| 目标设定 | 明确转型愿景后转化为实际目标和行动 |
| 可观测性 | 云原生分布式系统需持续洞察服务行为 |
| 持续教育 | 帮助团队不断提升云原生知识和技能 |
| 内部开源项目 | 非核心业务软件需求使用开源解决方案 |
| 选项与对冲 | 研究后聚焦有潜力的转型路径并发展 |
| 定期检查 | 业务环境变化时重新评估愿景和目标 |
| 共创的个性化关系 | 高人际连接团队协作解决复杂问题 |
| 平台团队 | 负责构建和运行统一的云原生平台 |
| 私有云 | 通过互联网或本地基础设施提供云服务,限制访问 |
| 有效反馈 | 舒适的反馈环境促进员工参与和创新 |
| 概念验证(POC) | 全面采用解决方案前构建原型验证可行性 |
| 心理安全 | 团队成员无惩罚担忧时更能自由思考和冒险 |
| 公共云 | 尽可能使用公共云供应商的硬件 |
| 降低实验成本 | 验证想法时尽量降低实验成本 |
| 参考架构 | 提供标准系统架构文档,提高一致性和复用性 |
| 反思休息 | 业务周期中定期回顾策略以适应市场变化 |
| 远程团队 | 分布式团队定期面对面交流并建立高效沟通渠道 |
| 可重现开发环境 | 开发者在接近生产的环境中测试工作 |
| 行动研究 | 通过小实验实践学习,增强决策信心 |
| 降低风险的部署策略 | 采用策略减少生产系统变更问题 |
| 从一开始确保系统安全 | 平台早期版本就融入安全设计 |
| 自助服务 | 云原生环境中团队可自行进行配置和部署 |
| 无服务器 | 未来是云上事件驱动、即时扩展的服务 |
| SRE 团队 | 协助开发团队维护和改进应用 |
| 拆分单体应用 | 逐步将旧单体应用拆分为微服务 |
| 拆分单体组织 | 转型过程中组织和团队同步进化 |
| 三阶段规划 | 合理分配资源到交付、创新和研究 |
| 转型冠军 | 认可和授权推动转型的人员 |
| 价值层次 | 明确组织价值观,支持日常决策 |
| 愿景先行 | 定义转型路径为行动指明方向 |
9. 转型的核心要点总结
云原生转型不仅仅是技术的变革,更是组织整体的变革,涉及技术、流程和文化三个关键方面。这三个方面需要协同发展,任何一方的滞后都可能导致转型面临挑战。以下是具体要点总结:
- 技术层面 :采用容器化应用、微服务架构、自动化基础设施和测试等技术,构建灵活、可扩展的系统。
- 流程层面 :实施持续集成、持续交付和持续部署等流程,确保代码的快速迭代和高质量交付。
- 文化层面 :建立学习型组织,鼓励创新和协作,营造心理安全的工作环境。
10. 未来的发展与挑战
云原生技术的发展日新月异,企业在转型过程中需要不断适应新的变化。未来可能面临的挑战包括:
- 技术更新换代快 :需要持续学习和引入新的技术,以保持竞争力。
- 安全问题 :随着系统的分布式和开放性增加,安全风险也相应提高。
- 人才短缺 :云原生领域的专业人才相对匮乏,企业需要加大人才培养和引进的力度。
为应对这些挑战,企业可以采取以下策略:
- 持续教育和培训 :为团队提供定期的培训和学习机会,保持技术的先进性。
- 安全体系建设 :从系统设计的早期阶段就融入安全机制,建立多层次的安全防护体系。
- 人才战略 :吸引和留住优秀的云原生人才,同时培养内部员工的相关技能。
以下是应对挑战的策略 mermaid 流程图:
graph LR
A[未来挑战] --> B[技术更新换代快]
A --> C[安全问题]
A --> D[人才短缺]
B --> E[持续教育和培训]
C --> F[安全体系建设]
D --> G[人才战略]
11. 结语
云原生转型是企业在当今快速变化的市场环境中保持竞争力的关键举措。通过采用合适的模式和策略,平衡效率和创新,企业可以构建一个灵活、自适应的组织。虽然转型过程中会面临各种挑战,但只要技术、流程和文化协同发展,企业就能够实现成功转型,解锁应对不确定性的能力,在未来的竞争中脱颖而出。云原生不仅仅是一种技术,更是一种思维方式和组织变革的动力,将引领企业走向更加美好的未来。
超级会员免费看
65

被折叠的 条评论
为什么被折叠?



