言之无物

我说的一切都是错的

译文——为什么开发人员要参与轮值

原文地址:https://skeltonthatcher.com/blog/build-run-developers-also-call/

一切都围绕反馈环

《译文——为什么开发人员要参与轮值》

很多开发人员都熟悉持续交付管道,它是一个相互协作的过程,反馈环存在于过程的每个阶段。 产品、开发和QA一起定义新功能,开发人员利用TDD完成功能开发。TDD本身就是一个反馈环,通过不断的测试来指导开发进程。代码在主干上编译,运行单元测试。 接着应用会部署到测试环境,进行一系列验收测试。所有这些反馈不断的为生产环境部署提供信心。测试完成后,开发人员把部署工作交接给运维,然后开始新一轮的功能开发。

看起来没毛病,很符合我们的思维习惯,但并不正确。问题在于开发人员过早从交付管道中退出,把工作扔给了墙外的团队,反馈因此中断了。

把墙拆掉

要构建可靠、贴心的应用,获取应用在部署/运行中的反馈是非常重要的。从管道构建开始,我们一直都依赖反馈环,但是应用一旦部署成功,反馈环似乎被丢弃了。 代码的价值只有被终端用户使用才能体现出来,用户的反馈是所有反馈中最重要的,但是我们作为开发者,却没有收到。

《译文——为什么开发人员要参与轮值》

可能是组织级的原因导致了隔离:传统的做法都是开发写代码,运维维护服务。 Devops提出了一种新的文化,让开发和运维走的更近。比如,开发能及时获取生产环境的反馈。 生产日志分析是开发获取反馈的一种方式。通过错误信息能洞察系统的薄弱环节,并持续完善。

洞察系统的另一种方式是建立指标采集服务。指标可以来自系统本身,也可以根据业务需求来定。 比如,信用卡和借记卡数量比这个指标,数据很容易采集,可用来解答这样的问题:“从特定的api端点上接收了多少请求,是否可以取消?”(其实我也没看懂!)。指标以百分比的方式采集,除异常点,让反馈专注于主要的用例,而不仅仅是告警。

这些自动记录的反馈几乎可以实时的获取,要完善系统的心智模式,还有很长的路要走。离完全拥有应用也还有一定差距。

更努力,更好,更快,更强

开发人员对自己开发的应用有完全的控制权,并且直接负责应用的运行。提供了另一种视角来审视“什么是重要的”,“需要关注什么,哪些不需要关注”。开发过程中看起来微不足道的问题,到了运维阶段,可能会影响你的个人生活,特别是当你的电话响起时。 偶尔的内存泄漏在白天不是什么问题,只要重启服务就可。但如果出现在晚上,就完全是另一回事了。 都知道显示错误页面是一个很不好的用户体验,由于简单的重启能解决,从而忽视了从根源上解决问题。现在,到你还债的时候了,不得不优先处理这些运维问题。

开发人员轮值是指标驱动开发的演进,当应用发生错误时,开发人员通常是最清楚如何来解决的。 随着应用上云和硬件基础架构的成熟,应用错误会比基础设施问题更多。 当微服务普及,消息成了服务之间的粘合剂,就需要开发人员的系统知识来定位根源,让应用尽快的恢复正常。

驱动力有三大要素:自主、专精、目的。拥有完全的自主权,才会有目的,并驱使自己精通相关知识让系统变得更好,自主决定修复优先级。我相信,这样的自主权,让我们对构建的应用感到自豪。

点赞

发表评论

电子邮件地址不会被公开。 必填项已用*标注