乐趣区

关于转型:另辟蹊径传统银行供应商系统持续交付之路-IDCF

jiezi

传统银行有大量的供应商零碎，更有甚者，比方咱们负责的业务部门，还要重度依赖供应商继续地进行定制化开发和修复。

个别谈到继续交付或自动化部署，都是具备最新架构思维的自主开发方面，或者是利用 Ansible、蓝绿部署、容器等实现应用程序的疾速部署等办法。

但大多数供应商零碎的设计古老，变更重度依赖数据库更新（很多逻辑通过存储过程来实现）。面对这样的零碎，要实现继续交付，须要另辟蹊径。

咱们治理的供应商零碎是一个服务于寰球 包含亚洲和欧洲 10 个国家和地区的单体利用 ， 是基于.NET 和 Oracle 数据库开发，运行在 Windows Server 和 IIS 服务器上的。每个月有超过 20 个变更须要公布到生产环境。**

咱们始终采纳月度公布的节奏。每次公布的范畴大、危险高，须要寰球各地业务部门加班配合测试，执行工夫长。因为保护工夫窗口（没有业务应用，可停机的工夫）只有周末和工作日早上 6 点至 8 点，要进步公布频率，只能靠加班，显然不可继续。

一、指标

为了疏导各部门实现 DevOps，公司定了明确的指标—— 公布次数翻倍，故障数减半。 尽管咱们并不关注具体数字，但这也给了所有部门方向与压力。对于咱们来说，如何在不加班的状况下实现在工作日公布成了具体指标。

二、重要发现

咱们对系统和公布过程做了深入分析，得出以下的重要论断：

大部分的公布是数据补丁，这些数据补丁只影响单个国家或地区，范畴小，危险低。如果在工作日就把这些数据补丁公布了，既可大大放慢其业务价值的实现，进步业务部门的满意度，也解决了咱们“80% 的问题”（柏拉图定律）。 残余的多数有寰球影响的其余补丁，则持续在月度公布（周末）实现，但剔除了大部分数据补丁后，其范畴曾经大大放大，危险也升高了。**

另外，因为数据补丁只影响单个国家或地区，咱们不用拘泥于早上 6 点至 8 点这个寰球保护工夫窗口。因为每个国家或地区的业务工夫不一样，咱们齐全能够依据各个国家或地区的业务工夫制订相应的数据补丁公布工夫窗口，比方香港是早晨 11 点到次日 8 点，欧洲是凌晨 2 点到下午 4 点等，给了咱们更大的灵活性。

三、实施方案

过来，供应商提供了补丁后，咱们 IT 团队须要手动部署到测试环境，而后告诉业务测试。这个过程费时费力，也没有什么价值。思考到供应商驻场人员能够拜访咱们网络与 Github，咱们思考把这个过程自动化了，拟定了以下的流水线设计：

3.1 测试环境

指标：IT 团队不须要染指

  • 供应商驻场人员把补丁公布提交到 Github 的测试分支，触发相应的 Jenkins Job；
  • Jenkins Job 触发公司自研的数据库主动部署工具，把脚本部署到相应的测试环境；
  • 咱们要求供应商在提供补丁时，也要提供相应的验证脚本，在部署时一起执行；
  • 验证通过后，咱们告诉业务开始验收测试（UAT）；
  • 验证不通过，验证脚本会抛出异样，部署工具会告诉咱们执行回滚。

3.2 生产环境

指标：在保护工夫窗口定时主动公布

  • 当该补丁用户验收测试（UAT）通过后，咱们把它合并到 Github 的 master 分支，并按公司规定发动公布审批流程；
  • 设定相应 Jenkins Job 的打算执行工夫（下一个工作日中该补丁波及到的国家或地区的保护工夫窗口）；
  • Jenkins Job 触发数据库主动部署工具，把脚本部署到生产环境；
  • 验证脚本通过后，公布胜利；
  • 验证不通过，咱们将收到告诉，上线执行回滚。

四、成绩

通过这套计划，咱们实现了以下几个指标：

  • 大部分的数据补丁不须要等到月度公布才上线，实现了继续交付，大大放慢了其业务价值的实现，进步业务满意度；
  • IT 从部署这项费时费力、价值不大的工作中解放了进去，能够做更有价值的事件，如业务需要或故障剖析；
  • 补丁公布上线不再是一项高风险的事件，业务和 IT 都不再对每次公布战战兢兢；
  • 大大减少加班工夫；
  • 每月公布次数从 1 到 2 次回升到十几次，因为每次公布的范畴小，危险低，也缩小了因公布引起的故障数量，满足了公司的 DevOps 指标。

五、落地难点

实际过程总不是一帆风顺的，咱们在过程中也遇到了很多问题，这部分能够分享一些咱们针对落地难点的做法，以供参考。

5.1 进度保障

因为日常的交付和保护工作占用了咱们简直全副的工作工夫，文中提到的这类重要而不紧急的事件通常都会无疾而终。为了防止这种状况，咱们利用每日站会来探讨落地细节和跟踪进度。

咱们把站会分为两类：一、三、五探讨日常工作；二、四探讨这个流水线的施行。

这样咱们便可确保每天都有进度，并在一个多月的工夫内实现了预约指标。

5.2 主动验收

因为公布到生产环境的过程可能是在非工作工夫内主动进行的，咱们须要有主动验收公布后果的过程，以确保零碎在公布后能失常运行；当验收不通过时，触发公布失败，告诉咱们执行回滚操作。

这就须要供应商在提供补丁脚本时，也要提供验收脚本，作为部署的一部分，自动测试补丁部署后的后果是否合乎预期。

举个栗子：

DECLARE
    NumberOfPatch_Actual number;
    NumberOfPatch_Expect int:=2;
BEGIN
    select count(*) into NumberOfPatch_Actual from USERS where a.user_id = 'USERA';
    If
        NumberOfPatch_Actual <> NumberOfPatch_Expect
    then
        RAISE_APPLICATION_ERROR(-20001,'Error, This is testing for the log capturing');
    END if;
END;
/

这种变相的测试驱动编程（TDD）的思维须要供应商习惯和配合。

5.3 主动回滚

有了主动验收，如何实现主动回滚，从而使整个过程齐全自动化，是咱们其中一个思考点。然而因为补丁执行过程有若干步，很难预知每一种的失败情景，最终咱们决定还是采纳手动回滚比拟稳当。

5.4 失败告诉

当验收脚本运行不通过时，意味着公布失败，如何让在工作工夫外的咱们失去及时的告诉，立刻上线执行回滚操作，是确保零碎失常运行的要害。

然而目前咱们的流水线零碎只能收回邮件告诉，没有针对手机的即时告诉伎俩，这一点仍须要寻找更无效伎俩。

六、总结

常说的继续交付和自动化部署计划大多是针对自主开发和应用程序的。

对于设计古老的供应商零碎或遗留零碎，少数变更在数据库上实现，要实现继续交付，可能须要另辟蹊径。

在思考计划前，要深刻了解你的零碎和公布过程；利用每日站会，继续探讨落地细节和跟踪进度，确保指标达成。

作者：IDCF 社区分享嘉宾 刘华
《猎豹口头：硝烟中的麻利转型之旅》作者

退出移动版