day 26 - 如何知道我交出了一个有品质的系统

这几天纪录下开发流程中可能会考量的项目跟使用工具纪录, 在开发完成到系统交付之後, 又是另一个阶段的开始。
当每个系统都只是微服务底下的一环, 要怎麽知道我交出了一个有品质的系统呢？
大概有几项可以作为参考：

• OnCall 次数
  以我们团队的现况来说, 服务都是在K8s上面运作, 团队中的成员两两一组, 每周有两位值日生负责当周值班来处理问题。在微服务底下, 每个成员手上都会有多个系统在运作, 一开始上线通常都是手忙脚乱、全员备战的状态,被Call的次数可能也很频繁, 各种未预期的状况会如雨後春笋般的接踵而来
  但经过一段时间之後(大约6个月), 接到电话的次数就应该要慢慢地减少, 这就是系统开始稳定的一种参考依据。

• 临时维护次数
  临时维护是指在非正常维护期间需要挂上系统维护紧急修复功能的时候。通常这时候是发现重大瑕疵, 必须要马上修复的情况, 除了修正程序, 可能还需要大量修正旧资料, 系统上线後都会遇上几次, 那也是一个兵荒马乱
  同样地, 在上线一段时间之後, 临时维护的次数也应该要变少, 表示每个系统都在预期内稳定的运作着。

• K8s上服务存活的时间
  k8s上面可以看到每个服务最近一次重启之後的的运行时间。我们的正常维护周期为14天, 每个维护日可以更新功能和修正bug, 有些系统会在上线前进行烧机测试, 要确保它无论如何都要能撑过14天不会重启。所以在K8s上的存活时间可以用来判断系统被异动的次数是否很频繁, 频繁被异动的系统同时也存在着风险, 这也可以作为一个参考。

• Error Log 数量
  我们的系统Log都会透过ELK集中收集起来, 而Log等级大於Warning的则会被发送到Telegram工作窗。系统会发生Error的情况大多会在测试阶段被发现, 但还是会存在漏网之鱼, 随着系统上线後逐步地补强渔网让系统趋近稳定, Telegram跳警报的次数也会随着慢慢变少, 手机越来越安静, 也是判断系统稳定的一种参考值

• Bug数量
  这是检视个人交付的系统品质的指标, 系统bug大多是在开发系统的过程中未注意到的情况, bug可以透过各种测试方式来减少在交付後才发生的状况, 像是TDD、BDD等各种测试方法都是辅助工程师检视专案品质的工具。回归到系统本质上去检视, bug越少的系统也会相对的稳定一些, 所以它也可以做为系统是否稳定的参考值。

今天大约分享几个检视系统是否稳定的参考值, 一个有品质的系统或专案不会只是一个点做好做满就可以达成的, 而是需要每个环节去反覆的检视跟调整, 系统会随着时间而日趋成熟跟稳定, 稳定的系统或许就可以称其为一个有品质的系统, 一个有品质的系统才能让工程师享受有品质的生活