7 大迹象，表明你的 DevOps 做对了！

据预测, 未来 10 年中, 企业或组织的数字化转型会达到高峰, 将比过去几十年的总和还要多。而这一进程, 开发工程师必须找到更加有效的开发方式, 才能实现。

在这一层面来说,DevOps 是数字业务转型计划的核心。目前, 企业越来越重视 DevOps, 并开始向这种开发方式转型。但是, 如此多声称专注于 DevOps 的企业或组织, 真的都做对了吗?

在大多数的 DevOps 实践中, 仅仅涉及到了特定工具的使用, 企业非常松散地遵循着某些 DevOps 原则。然而, 要想真正成为一个以 DevOps 为中心的组织, 这些远远不够。参照以下 7 点, 或许能够帮助你及时纠偏:

一、部署是完全自动化的

每一个项目工程通常都包含了很多的代码文件、配置文件、第三方文件、图片、样式文件等不同部分, 要想将这些部分有效组装、最终形成最后的应用结果, 往往需要借助构建工具或策略。

构建过程如果仅仅依赖人工, 就会十分繁琐。于是, 自动化构建、自动化发布、自动化部署的想法和探索就浮现了。自动化的出现, 将大大提升工作效率。

在 DevOps 实践中, 是需要从头到尾完全自动化部署的。自动部署的意义不仅仅在于节省时间, 更多是避免问题的出现, 手动部署更常出现因为人为错误引起的问题, 而自动部署可以在问题出现时迅速恢复到以前的版本。

二、有频繁且快速的发布周期

天下武功唯快不破。想要获得更强大的竞争力, 只有不断部署和快速修复。DevOps 中一个核心功能就是 CI / CD (持续集成 / 持续交付), 寻找更有效的自动化和部署更新迭代的方法, 让开发人员提高生产效率、并快速地发布到生产环境中。

CI / CD 通过在构建、测试和部署应用程序时强制自动化完成。这种 DevOps 方法的精髓在于:

1) 通过频繁的代码库提交、自动化构建等来提高生产力;2) 通过集成自动化测试以及开发期间的测试, 增加在开发早期发现错误的机会;3) 得益于频繁的测试和自动化部署系统, 可以更快地发布版本。

三、注重可观察性

国外的一份报告显示, 可观察性正在成为 DevOps 实践中绝对不能缺少的一环。在跨越多个流程的数字业务转型中, 可观察性有非常重要的意义。

New Relic 对 1300 名 IT 领导者、软件工程师和开发人员进行的一项全球调查发现,90% 的受访者认为可观察性对业务至关重要。只有更多地基于事实而非直觉, 才能作出明智的决策, 越来越多的团队开始从整个企业应用程序环境中收集数据, 来提高整个开发过程的可观察性, 可观察性也在生产前和生产后的环境中扮演越来越重要的角色。

四、有持续的反馈循环

初期,DevOpsDays 活动的发起人和 DevOps 这个词的创始人 Patrick Debois 发现, 有关 DevOps 的话题相互交织在一起形成了四个不同的反馈环, 如上图所示。

其中, 蓝色气泡代表技术, 黄色气泡代表过程管理。一起形成了 4 个循环。开发-测试反馈环 (黑色箭头反馈环); 开发-运维反馈环 (绿色箭头反馈环); 业务-运维反馈环 (红色箭头反馈环); 业务-用户反馈环 (紫色箭头反馈环)。

在现在的 DevOps 理念中, 出现错误并不可怕, 可怕的是没有一个持续的反馈循环系统来检测何时何地出现问题。反馈循环需要在发生错误时快速通知, 从而使问题得到更快地解决。

很多时候, 我们遇到问题仅仅是简单地解决了它, 并没有花时间分析问题发生的原因以及如何防止问题再次出现。这样的循环是不完整的。从某种程度上, 如果你设置了一个系统来识别问题、修复问题和改进问题, 还需要认真分析, 才意味着你在正确地实践 DevOps。

具体来说, 一个监控系统需要观察并记录系统状态变化和数据的流程：1) 状态的变化: 可以通过状态的直接度量或者更新日志来表示;2) 数据: 可以通过记录内部组件和外部系统之间的请求和响应来记录。

五、开发和运营团队一起工作

Dev (开发) 和 Ops (运维) 的矛盾主要是面向适应性的敏捷软件交付和面向经验性的传统运维之间的矛盾。这个矛盾最先由 John Allspaw 和 Paul Hammond 在"10+ Deploys Per Day: Dev and Ops Cooperation at Flickr"提出, 并以"Cooperation"作为整个演讲的核心, 讲述了他们解决这个矛盾的实践经验。

在一个组织中, 如果相关利益者的利益不一致, 在既定流程的进行中一定会碰到诸多阻力。而在这一点上, 首先做的就是把 Dev 和 Ops 的利益一致化, 从而减少 Ops 对软件交付的阻力。

在传统观念中, 开发的工作是增添新的功能, 而运维的工作则是保证站点的稳定和高性能。而在 DevOps 的观念中,Ops 的工作目标应该是激活业务 (enable the business), 与 Dev 是一致的。

至此,DevOps 众所周知的主要好处就是打破开发和运营之间的孤岛。在维基百科上,DevOps 的解释也着重于一种重视"软件开发人员 (Dev)"和"IT 运维技术人员 (Ops)"之间沟通合作的文化、运动或惯例。因此, 开发、测试和 IT 运维团队之间的沟通对于 DevOps 的成功至关重要。

六、目标明确

虽然不同团队之间的沟通至关重要, 但明确定义每个人都在努力实现的目标同样重要。归根结底, 所有团队都有同一个目标: 让组织更有效率。

但是, 他们为实现这一目标而遵循的个人实践可能会有所不同。团队成员应了解实现目标所需满足的精确要求, 而不是做出假设或任其发展。

七、使用正确的工具和平台

DevOps 不仅仅是一种文化转变 -- 它需要强大的工具才能实现。在实践过程中, 如果你发现往往需要花费大量时间来解决出现的问题, 那么很可能是因为你没有选择正确的 DevOps 工具。

幸运的是, 目前的市场上有大量且广泛的 DevOps 工具可以选择, 以适应当前现有的所有的数字化基础设施。尽管工具是 DevOps 的重要组成部分, 但是要记住, 真正使改变发生的是实践。

在众多 DevOps 工具中, 近两年来被业内广泛关注的飞算 SoFlu 因其对软件开发流程的变革而被大量企业应用于 DevOps 落地, 飞算 SoFlu 是一款管理加开发工具, 通过可视化编程的方式满足开发需求。使用平台的一个 ID 相当于一个 10 人科技团队, 从而使用户有更多精力可以更多关注自身业务。飞算 SoFlu 中包含的三大核心技术, 全都是 DevOps 实践中所要关注的重点:

1) 可视化开发

改变传统开发方法, 业务逻辑可视化展示, 降低开发门槛, 无需编写代码, 在设计业务逻辑时就形成微服务应用。

2) 平台组件

可视化平台组件是一类通用的技术功能模块, 平台支持循环条件判断, 函数调用, 通过拖拽方式以及参数配置实现等同于编写复杂代码的业务逻辑, 有别于通过组件排列组合。

3) 管理方式

主要通过管理平台来管理需求、研发、测试、部署、上线、运维等整个软件生命周期, 经验沉淀、知识积累, 将管理制度真正的落地。

截至目前, 飞算 SoFlu 已为包括医疗、金融、制造、零售等在内的八大行业的上百家机构提供了技术服务, 助力其落地 DevOps, 提升研发效率。

一个典型的案例是, 飞算 SoFlu 在某大型国有银行的应用。该银行原本需要 3 天才能开发完成的接口, 使用飞算 SoFlu, 仅用了 5 个小时。其 IT 负责人表示, 使用飞算 SoFlu 后, 银行软件中心的整体研发效率获得了大幅提升。

飞算 SoFlu 的 DevOps 功能正是在不断的实践中完善升级, 从实际业务出发, 真正让企业实现降本增效。