建立规律问责制_改变现状：如何在组织中建立问责文化

最新推荐文章于 2024-11-11 20:35:54 发布

danpu0978

最新推荐文章于 2024-11-11 20:35:54 发布

阅读量441

点赞数

文章标签：大数据编程语言 python 机器学习人工智能

原文链接：https://www.javacodegeeks.com/2018/11/changing-status-quo-create-culture.html

版权

建立规律问责制

如今，毫无疑问，软件确实正在吞噬整个世界。我们生活的每个部分都包括软件，从我们看电影的方式到我们乘车，预订酒店，交流，购物等方式。

马克·安德森（Marc Andreessen）的文章“为什么软件在吞噬世界”，讲述了这个故事，并揭示了为什么所有公司现在都是软件公司。转向软件驱动的思维方式已经带来了许多挑战，因为新的竞争和创新步伐给领导层，业务部门和IT组织带来压力和压力。

您如何促进公司的Dev和Ops之间的合作？ 随着新架构和技术的不断涌现，我们对2500多名技术专业人员进行了调查，以了解有关这两个职能之间不断发展的关系的更多信息。 在此处获取完整报告 ！

新世界，新期望

在这个软件正在吞噬世界的新时代中，客户的期望已发生了巨大变化。耐心已成过去。容忍缓慢的响应时间，错误和安全漏洞，只需单击一下鼠标就可以将客户转移到其他地方（他们不必再开车穿过城镇了）。更糟糕的是，客户不仅会继续参与您的竞争，还会通过社交媒体让其他人知道他们的体验。您的应用程序需要可靠，否则您很快就会感到客户的愤怒。在这个新世界中，品牌失去光泽的影响是真实的，可能的，并且寿命比以往更长。

IT如何尝试处理应用程序可靠性？

应用程序的可靠性对于每个大小公司来说都是一个持续的挑战。为了应对这个新世界中的挑战，IT部门正在使用工具，流程和人员进行武装。在这些工具中，您可以找到自动化测试，日志聚合器，APM，静态代码分析器，错误跟踪器等。这些过程包括敏捷方法论，同行评审和回归测试。创建了新的团队和角色，例如站点可靠性工程师（SRE）和DevOps，以弥合开发，部署和运营之间的差距。

尽管采取了所有这些措施，应用程序的稳定性和可靠性仍然是一个持续的挑战。

有人真的知道应用程序内部发生了什么吗？

在过去的十年中，我已经与数百家公司合作，并且了解了很多有关如何部署和管理应用程序的知识。公司接受每天重新启动应用程序作为解决隐藏问题的解决方案，这些问题包括：内存泄漏，文件句柄限制以及其他导致应用程序故障的未处理代码问题。每天许多错误会发生数千次，但从未得到解决。我经常听到这样的说法：“有成千上万的错误，我什至不知道哪些错误值得我花时间去调查？” 过多的日志记录做法会导致日志文件变得很大，影响应用程序性能，并在发生中断和sev1问题时产生噪音。

为了使事情变得更复杂，日志仅考虑工程师期望看到错误的区域。这会造成数据缺口，因此无法确定发生错误的全部范围。什么时候可以解决所有问题且看不到解决方案？

如果没有人抱怨，我为什么应该关心我的应用程序是否有错误？

我经常被问到这个问题。如果客户或用户没有抱怨某些东西坏了，我为什么要关心？这里确实有两个论点。

首先是：仅仅因为您的客户没有打电话投诉，并不意味着他们没有登录Twitter进行投诉。这并不意味着他们没有离开您的竞争对手，也不意味着他们遇到的问题不会导致停机和更多错误。

第二个是：您应该注意，因为每个错误都有代价（请参阅下文）。零收件箱应该是每个开发团队的目标。这意味着更少的停电，深夜支持电话和作战室……您可以恢复生活。

“如果错误未记录在日志中，是真的发生了吗？ 错误很可能发生，并且OverOps可以量化错误并提高应用程序的置信度。 我已经看到开发人员在5分钟内发现OverOps存在的问题，因为他们认为这不存在。”
-拥有20年技术开发和运营经验的Deerek D'Alessandro

应用程序错误的真正代价是什么？

应用程序错误有两个方面的成本。存在软成本，例如客户流失，品牌失去光泽，额外的员工要求和较低的工作满意度（开发人员很快就厌倦了调试代码问题）。这些很难量化，我们使用“客户的终生价值”和“失去员工的实际成本”之类的公式来帮助衡量成本。

其他成本称为“硬成本”。该开销包括日志聚合器的成本（包括不断增长的日志存储和索引成本），附加的硬件/存储/网络以及APM工具。过多的错误会影响CPU性能，可能会大大增加日志量，并留下未知的副作用，这些副作用会在以后导致中断。

“应用程序必须尽可能合理地保持稳定，长期经历过一次或多次不良体验的客户是社交媒体中强大的网络贬低者。 在单个客户看到新的应用程序发布之前，OverOps可以提供有关运营质量的宝贵见解。”
-拥有20年技术开发和运营经验的Deerek D'Alessandro

问责文化

在成为现场工程师之前，我管理着一支工程团队，为大型保险公司编写软件超过十年。他们针对规模，性能和可靠性的SLA使得我和我的团队长时间工作，并且始终在寻找改进的方法。我们的团队目标是无错误的98％，我们彼此负责。

我们这样做的一种方式是，如果有人破坏了申请，他们的名字就会出现在董事会上。这意味着每个人（包括我们的领导层）都可以了解我们的开发过程。当名字出现在董事会上时，这意味着有机会学习和改进。作为一个团队，我们集体讨论了这个问题，然后在我们的代码库中搜索了其他此类情况，并进行了修复。

这次练习产生了一个相互信任，互相尊重和学习的开发人员团队。如今，越来越难以找到这种责任感，因为团队越来越要求以比竞争对手更快的速度提供新功能，从而导致更短的期限和更少的时间来学习错误。

现在，我看到代码被“扔在篱笆上”供其他人处理。这会导致敌意，瓶颈，指责，最终导致可靠性较低的应用程序。现在是改变文化的时候了。

更改状态

现在是时候让团队和团队成员对自己的代码负责，而不是编写和忘记它。为了做到这一点，应用程序团队需要知道他们的应用程序内部发生了什么。他们应该知道每天每一分钟发生了多少错误和日志记录事件。如上所述，每一个都有成本，并且目标应该是没有已知或未知的错误。

如果每个人都承担责任，那么应用程序将以更高的标准运行。没有错误的后果将是巨大的。

由于内存泄漏或文件句柄限制，将不再需要重新启动。
原木会更干净，并且通过噪声找到信号会容易得多。
当出现实际的应用程序问题时，进行故障排除会更容易，更快捷。
应用程序将更好地扩展，因为不会在错误处理上浪费CPU。
客户不会抱怨或离开您的竞争对手。

如何在运行时在应用程序内部获得可见性？

如上所述，我们应该知道整个软件开发生命周期中应用程序中发生了什么错误。这怎么可能？ OverOps是一个应用程序可靠性平台，可捕获应用程序中发生的每个错误以及log.warn和log.error事件，包括以前从未发现的事件，如“吞咽异常”，这些事件从未显示在日志中。

捕获的数据正在改变游戏规则，因为开发人员和运营团队将对正在运行的应用程序具有100％的可见性。事件会细化到代码中带有错误计数和错误率的方法。最后一个重要组件是ARC™（自动根本原因）屏幕，该屏幕显示错误发生时正在执行的代码以及正在应用程序中移动的数据。

“给我看数据。如果无法衡量，就无法理解，也无法解决”，–匿名

OverOps的成功范例

第一个例子，一家大型的SaaS公司每天发生1500个独特错误，每天发生十亿次以上。 CPU和日志记录的数量导致规模和云成本方面的问题。 OverOps中的可见性帮助他们确定了最昂贵的错误的优先级，并且通过修复这些错误，他们能够将应用程序服务器的数量从200个减少到100个，从而减少了云支出并具有扩展能力。

我们的第二个示例是一家大型信用卡公司，该公司一直在努力应对规模和间歇性断电情况。他们打开OverOps，立即看到100个错误，其中65％被误吞为异常。这些类型的错误永远不会显示在日志文件中，并且所有团队都不知道。完成了简单的成本/性能计算，发现了100个小时的CPU时间损失。固定代码后，延迟减少了大约10％，从而提高了应用程序吞吐量。