云原生应用架构中的文化变革 一：秉承精益制造之魂，启行 DevOps 之路！

Posted 2021-08-30 魏小言

文章目录

• 在变革中前行
• • 文化变革在前行
  • • • 研发的使命
      • 运维的使命
      • DevOps
      • 精益制造
  • Q&A
  • 附录

在变革中前行

  云原生架构的使用，对企业来讲，不仅仅是技术的革新，更是 “文化” 和 “组织” 的变革！

文化变革在前行

• 为什么文化要进行变革呢？
    正如 1912 年，清王朝覆灭一样，“ 旧的 ”，“ 传统 ” 的企业文化与产品服务价值脱节，成为了产品服务升级中的拖油瓶！
    正如 2013 年提出的，社会主义核心价值观一样，“ 富强、民主、文明、和谐，自由、平等、公正、法治，爱国、敬业、诚信和友善 ” 才是新时期中国建设中的助力利器！

• 云原生架构中文化如何变革呢？
    调查众多企业中就会发现，企业 IT 往往会被组织成单个部门，即孤岛。比如：

  • 研发事业部「RD」
  • 质量保障部「QA」
  • 产品创新部「PM」
  • 系统部 「运维」
  • 数据组 「DBA」
    ……

• 为什么要进行孤岛建设呢？
    这样组织的目的是为了让专业的人员来管理和指导该领域的人员。这些孤岛往往有各自的组织关系、沟通风格、工具集、激励机制、等等。

  这些孤岛内涵差异，会出现为了企业共同的产品价值目标，各个孤岛采取不同的实现方式，即范式。

  这些范式的产生伴随了种种的矛盾，这些矛盾将会成为价值交付中的累赘、拖油瓶！

举个老生常谈的例子吧，”研发“ & ”运维“ 各自的使命…

研发的使命

  作为研发人员，通过开发功能为软件赋能，创造价值。这些功能的引入也将会作为研发的最终绩效，关乎着人员的年中奖及晋升，等等…

  而功能的引入本质是在交付变化！

运维的使命

  作为运维同学，通常以 sre 或者 系统平台的稳定性、可用性、弹性、等关键指标的稳定作为价值的实现。例如平均故障间隔时间（MTBF）和平均恢复时间（MTTR）。这些指标的波动影响着人员的年中奖及相关绩效、晋升、等等…

  这些措施相关的主要风险因素之一是在系统中引入任何类型的变更！

显然，由于范式的不同，在实现公共目标的过程中，种种的矛盾会使项目工作中的协作、沟通和简单的交接变得乏味和痛苦，严重与云原生中追求速度的思想不符！

DevOps

  DevOps 维基百科是这样定义的：

DevOps 是一组过程、方法与系统的统称，用于促进开发、技术运营和质量保障（QA）部门之间的沟通、协作与整合。

  了解 DevOps 历史的同学，可能知道，它完全是为应对上述孤岛场景而生，甚至更泛的开创了一种基于速度和质量的软件工程文化。

  在 DevOps 中，研发 和 资源/平台依赖部门向共同的直接领导者汇报，并进行合作，寻找能够持续提供价值并获得期望的可用性、弹性、性能和耐久性水平的实践。
  在这里你可以简单理解为，将这些信息孤岛构建成共享的工具集、词汇表和沟通结构， 然后创建激励结构，强制和奖励领导组织朝着这一目标迈进的行为。

精益制造

  这里引入一种实体经济中的思想 —— 精益制造。

从客户给我们下达订单开始，一直到我们收到现金为止，我们一直都关注时间线。而且我们正在通过删除非附加值的废物来减少这个时间表。
—— Taichi Ohno

  在软件工程中，尤其是云原生应用架构，有机的结合了精益的思想，追求价值交付的速度及质量，其生产过程将整个被信任和责任充斥！其中冗余的流程及文化组织都将会被遗弃！

Q&A

1、到底什么是 DevOps 呢？

文章重在指出文化变革需要前行，具体什么是 DevOps 可关注后续博文！

附录

开放心态，接纳万物，自我革新！