重新思考SDLC

你可以在推特上@editingemily找到我。我希望你把它变成你自己的。分享你的反馈。让我知道你如何把它应用到你的日常工作中。我的大部分工作都围绕着DevOps展开，我真的不能夸大DevOps对这个行业的巨大影响。在许多方面，它建立在敏捷的基础上，成为我们在日常工作中都能达到的默认值和标准。当DevOps在2008年作为一个想法出现时，科技行业处于一个完全不同的空间。

我的意思是，AWS还处于起步阶段，只提供少量服务。Azure和GCP还不存在，至少还没有公开。大多数公司维护自己的基础设施。开发人员编写代码，并依赖CIS管理员按预定的时间间隔部署新代码，有时间隔几周、几个月。容器技术还没有发明出来。应用程序遵循单片体系结构。数据库是关系型的，没有服务器是不可能的。一切，从应用程序到工程师，都是集中的。我们现在的生态系统已经大不相同了。

别误会我的意思。软件很难。它将永远如此，但我们将继续寻找真正新颖的解决方案来解决持续困难和持久的问题。其中一些想法最终是对旧想法的重塑，但另一些则是对复杂性的抽象或自动化工作的独特而聪明的采取，或者可能是最重要的，重新思考，甚至挑战我们多年甚至几十年来一直接受的前提。在DevOps试图解决开发人员和运维工程师之间的关键冲突的这些年里，DevOps已经成为一个笼统的术语，并且有许多衍生作品。

DevOps对5000个不同的人意味着5000种不同的东西。现在，对一些人来说，它被提炼为持续集成，持续交付，CICD。对于其他人来说，它更频繁地部署代码，增加并投资于测试、安全大门等等。对其他人来说，这是组织性的。他们已经增加了一个平台团队，甚至可能是一个名称可疑的DevOps团队，或者他们已经创建了一个专注于分离关注点的工程结构，让功能团队来管理他们竖井服务的开发、部署、安全和维护。

不管怎么解释，重要的是，DevOps是什么，或者它在执行中是什么样子，并没有一个普遍接受的标准。这是一种哲学。最重要的是，人们可以利用一个框架或方法来配置和定制他们的特定环境，以适应现代开发实践。DevOps的一个特点，我认为我们都同意，就是它试图捕捉整个软件开发过程的挑战。

没有一个衍生作品是那么雄心勃勃，那么大胆，而是只关注软件交付的一个部分。我认为，正是这种大范围的、全面的观点，我们应该再次赋予它生命。我们面临的挑战是，DevOps是一种针对以前问题的日益过时的解决方案。开发人员现在面临的文化和技术挑战远远大于如何更快地部署单一应用程序。Cloud Native是未来，是下一个默认决策的集合，DevOps的故事不能以目前的形式吸收它。

我相信DevOps的时代正在衰落，在这一刻，随着DevOps的夕阳西下，我们有一个独特的机会来重新思考、重建，甚至重新平台化。现在，我没有水晶球。我不完全确定下一个十年的科技会是什么样子。没有人能确定这一点，但我知道我一个人无法写出这个故事。

我需要你。我需要了不起的开发者社区。也就是说，我有一些想法，我认为可以开始对话。我相信，要在过去的基础上继续前进，我们必须抛弃我们一直以来认为理所当然的假设。为了前进，我们必须先后退一步。软件或系统开发生命周期，即我们所说的SDLC，自20世纪60年代以来一直在使用。从彩色电视和触屏电话出现之前，它就或多或少地保持着不变。

在过去的60年里，我们做了一些微调。我们加入了漂亮的颜色。阶段和步骤有点不同。在敏捷中，我们把它弯曲成一个圆圈，DevOps是一个无限循环，但在所有用例中，SDLC已经成为一个假设。我们都不再想它了。像SDLC这样普遍采用的结构具有不言而喻的持久性。

他们觉得自己一直都是，而且永远都是。我认为，如果你出生在这个概念普及之后，这种影响会更大。我们周围的一切几乎都是一个建构，一个模型，一个人类思想的产物。你坐的椅子，你工作的桌子，你喝咖啡的杯子，有时还有其他饮料。建筑，厕所，管道，道路，汽车，艺术，电脑，一切。

SDLC是一个遗迹，是上一个时代的产物。在这个时代，软件安全是一个身体上的问题，女性仍然被称为计算机。我觉得我们应该把SDLC扔了。更准确地说，我认为我们应该换掉它，换掉更能反映我们工作性质的东西。为物质产品制造商设计的单一、线性的模型不可能捕捉到现代社会技术系统的分布式复杂性。

它就是不能。这两种观点并不相互排斥。SDLC是改变行业的、有价值的、极具影响力的，是时候做点新东西了。我认为我们足够强大，可以同时持有这两种理念，在展望未来的同时尊重过去。无限符号被广泛用于可视化DevOps工具链。这是一种或多或少将SDLC弯曲成一个循环的方式，公司可以通过该循环进行迭代。就像SDLC一样，它意味着一个线性流程，即你计划，然后创建或开发，验证和测试，打包，构建等等。DevOps对SDLC的解释不允许根据需要暂停、枢轴或循环返回。

我不知道你是怎么想的。在我的生活中，我从未有过一个软件项目能够一气就地顺利进行，无论这个项目有多小，即使只有我一个人在做这个项目。软件开发是混乱的。这是一项关于熵的研究，它并没有变得更简单。我们用来思考和讨论软件开发的模型必须捕获我们工作的多线程、非顺序性质。它应该体现工程师所扮演的角色以及他们在开发过程中遇到的问题。它应该建立在敏捷和DevOps的基础上，并代表持续创新的迭代本质。

当我第一次开始思考这个问题时，我认真地思考了很久，我受到极限编程和螺旋模型等想法的启发。如果你不熟悉，值得一看。我想要一些有层次，甚至线程的东西，一种可视化地表示并行发生的多个进程的方法。我确定的是革命模型。我相信这种可视化能够捕捉任何软件场景的关键时刻。现在，我马上就会深入研究这些细节，但我想给你们一分钟时间来真正理解这个概念，给你们一个第一印象。

我称它为革命，因为，首先，它是旋转的。它的圆形形状反映了我们工作的连续和迭代性质，但也因为这是革命性的。我挑战的是一种已经存在了60年的模式，它已经融入了我们的日常语言中。我不期望它明天就能广泛地集成到生产工作流中。相反，我的任务是挑战现状，创建一个我认为更准确地反映现代云原生软件开发复杂性的模型。

革命模型由五个同心圆构成，它们描述了软件开发的关键角色:架构、开发、自动化、部署和操作。与每个循环相交叉的是六个辐条，它们描述了每个工程师在任何工程工作中必须考虑的生产考虑因素:可测试性、安全性、可靠性、可观察性、灵活性和可伸缩性。列出的考虑因素并不是包罗万象的。如果你这么想，那你就对了。当然，有些东西没有明确地包括在内，但我想，如果我在这里放20条或更多的辐条，我们中的一些人可能会有点不知所措，包括我自己。

您可能还想知道为什么操作比架构要小。是不是不那么重要?绝对不是。当我第一次设计这个模型时，我从建筑中寻找灵感。古根海姆博物馆有一个这样的形状引起了我的注意。它有一个令人惊叹的圆形斜坡，你们很多人可能很熟悉，甚至可能走过。在一个完美的世界里，这个模型应该是三维的，显示层次，甚至运动。但我相信，任何模型，即使在二维可视化中，也必须保持其意义。

因此，其中一个角色必须是最小的。其中一个必须是最大的。我选择操作作为最里面的部分，因为它对我来说代表了软件的过程。当我们在设计的时候，我们的想法是大的，我们是抽象的，设计的，梦想的。在那一刻，一切皆有可能。但是当我们进行软件交付时，我们变得更加嵌入系统，我们的选择变得更加受限。

现在让我们更深入地研究这些元素。首先是角色。这是一种新颖的思考方式。长期以来，我们一直将人物角色作为划分受众和定制信息的默认方式，本质上是分组。现在世界上的每一家公司都在重复开发人员、开发人员、开发人员的咒语，但人物角色总是让我有点烦恼，因为我认为这种方法要么过度简化了某人的职业生涯，要么不必要地复杂化了它。

我的意思是，现在很少有人能像开发人员和运营人员那样完全地归入基于角色的类别。线路变得模糊了。另一方面，我不认为我们需要特别定制信息来区分DevOps工程师和发布工程师之间的区别。这根本没必要。但也许最关键的是，我相信人物角色是不可改变的。一个人物角色完全取决于一个人如何定义自己。

这是内在的，不是外在的。他们的头衔可能会改变。他们的工作可能有所不同，但他们可能仍然在无处不在的下拉列表中选择相同的角色，我们在注册某些东西时都必须从中选择。我是一个开发人员。尽管我在DevOps、AIOps、DevRel等其他领域做了大量工作，但我始终认为自己是一名开发人员。在我心里，我是一个开发人员。我首先从这个角度考虑问题。它影响着我的思考，我的观点，我的方法。

角色非常不同。角色是暂时的、不一致的、不断波动的。如果我是一名演员，我要演的角色会很长很多样，因为我自然会成功，但我所认同的角色仍然是演员，艺术家。你的工作不局限于一套技能。这可能是十年前的事，但不是今天的事。在任何给定的一周或冲刺中，你可能扮演一个架构师的角色，思考如何设计一个功能或服务;一个开发人员，编写代码，修复bug;一个自动化工程师，研究如何改进我们经常提到的手工过程;发布工程师，将代码部署到不同的环境或发布给客户;或者运营工程师，确保应用程序以一致的、预期的方式运行。

无论我们扮演什么角色，我们都必须考虑一些问题。首先是可测试性。所有软件系统都需要测试，以确保架构师的设计能够工作，开发人员的代码能够工作，操作人员的基础设施能够按预期运行，以及所有类型的工程师的代码更改不会导致系统崩溃。测试，在它的许多形式中，是使系统持久和有寿命的原因。它使工程师确信，变化不会影响当前的功能。一个没有测试的系统是一个等待发生的灾难，这就是为什么在这个特殊的圆桌会议上，可测试性是第一位的。

安全是每个人的责任，但很少有人知道如何设计和执行安全的系统。我们最近看到了这种情况。我是说，我很纠结。在大多数情况下，安全事件是我所说的高影响、低概率事件。真正的大灾难，那些最终上了新闻，让我们所有人都能免费获得一年信用报告的灾难，它们并不经常发生。感谢上帝，因为我们知道我们的系统中潜伏着无穷无尽的小漏洞。

安全是一件我们知道我们应该花时间去做的事情，但我们并不经常为它腾出时间。现在，让我们诚实地说，这很难，复杂，还有一点可怕。风险很高，术语也不一样。太多了。DevSecOps是DevOps的第一个衍生版本，它要求工程师将安全性向左移动。这种方法意味着安全性是过程早期的一个考虑因素，而不是在最后一刻阻碍发布的因素。但是这句话，“安全向左移动”，应该向你展示SDLC是如何嵌入到我们的文化中。

它依赖于SDLC这个短语。“将安全性向左移动”。这也是我对遵从性和治理的考虑。它们不是完全对齐的。你是对的。但我觉得所有需要请律师处理的事情都应该放在一起。严肃地说，这三个概念实际上是关于风险管理的。有不同的主题:身份、数据、授权。这并不重要。问题是谁能获得什么，何时以及如何获得。 And that is everyone’s responsibility at any stage.

站点可靠性工程，或SRE，是一门学科，一项工作，一种有充分理由的方法。应用程序和服务在绝大多数时间内按预期工作是绝对关键的。也就是说，可用性经常被错误地视为可靠性的同义词，但事实并非如此。相反，这只是概念的一个方面。如果系统可用，但客户数据不准确或不同步，则系统不可靠。可靠性有五个关键组成部分:可用性、延迟、吞吐量、保真度和持久性。

可靠性可能是最终结果，是我们努力的方向，但对我来说，弹性描述了开发人员可以采取的提高可靠性的过程和步骤。可观察性是洞察应用程序或系统的能力。它是遥测、监控、记录、警报的结合，工程师和领导层都可以使用。

可观测性和可靠性有重叠的地方。这就是为什么它们是邻居，但可观测性的目的不仅仅是维持一个可靠的系统，尽管这当然很重要。它是在一个系统上工作的工程师对该系统内部工作的可见性的能力。可观察性的概念实际上来自线性动态系统，它被定义为基于外部输出信息来理解系统内部状态的程度。当公司将系统迁移到云端或利用托管服务时，他们不会失去对系统的可见性和信心，这一点至关重要。

云存储、计算、所有类型的托管服务的共享责任模型要求工程团队能够在出现问题时迅速得到警告、识别和补救。灵活的系统能够适应客户和细分市场不断变化的需求。灵活的代码库可以很好地吸收新代码，它们体现了清晰的关注点分离，它们通常被划分为小的组件或类，并且在架构上支持现在和将来。在一个灵活的系统中，可以减少或消除链依赖，数据库模式可以很好地适应变化，组件通过标准化的、文档完善的API进行通信。

我们工作中唯一不变的就是变化。在我们扮演的每个角色中，创建随着应用程序增长而增长的灵活解决方案是至关重要的。最后,可伸缩性。可伸缩性指的不仅仅是系统对额外负载进行扩展的能力。它意味着成长，即系统随着时间的推移而成熟和繁荣的能力。革命模型中的可伸缩性承载了团队的持续创新以及系统中这种增长的副产品。hth华体会最新官方网站

对我来说，可伸缩性是所有考虑因素中最人性化的。它要求我们在不同角色中的每个人都考虑到我们周围的每个人:使用系统并依赖其服务的客户，我们的同事，当前和未来的同事，与我们合作的人，甚至是我们未来的自己。我们也必须编写/读取这些代码。软件开发不是一条直线，也不是一个完美的循环。这是一种不断变化的复杂舞蹈。

有旋转，旋转和困难的旋转，向前和向后。工程师们平行移动，创造出真正宏伟的艺术品。问题是那些纯粹的魔法，艺术的时刻，那些我们最好的，最完美的自我的时刻，它们转瞬即逝。首席芭蕾舞演员在练习中摔倒。有时也在演出的时候。首席小提琴手，一个不折不扣的音乐会大师，弹错了音。你的测试没通过您的代码无法编译。你的工作默默出错。生产失败。 That’s always fun.

你没有设定最后期限。首相疯了。他们总是很生气。这是一片混乱。我是说，那不是你。是电脑。这就是为什么我认为每个人都会生气和有压力。令人惊讶的是，我们期望软件开发是一条直线，但事实并非如此。它就像我们最喜欢的互联网服务提供商出现故障时的进度条。他们会说8分钟后你就能看到流媒体，然后是3小时，然后是2分钟，然后是2天。

我们继续以直线来衡量进步。产品发布时用红、黄、绿来表示。我很欣赏丰田的生产系统，也很欣赏DevOps圈子里对它的讨论，但我们不是在制造汽车。这不是一个清单。一旦你安装了司机侧门，它就一直在那里。在任何生产线上，安装门都不会导致催化转换器损坏，但您的小小更改，那一小段代码，可能会导致整个系统崩溃，或减慢来自完全解耦服务的请求。

我对这种新的模型和方法充满热情，因为我相信它将有助于开发人员的日常工作。当我们使用的模型是一条直线时，我们如何教导业务领导、产品负责人和scrum主管，在特性交付中进行预测是一件有点愚蠢的事情?

现在我不期望这个模型在六个月或一年之后看起来和现在一模一样。事实上，我几乎认为这是一个失败。我想要你们的观点和经验来塑造它，一个人和你在完全独特的环境中运作，但让我们看看革命在实践中会是什么样子。想象一下，在事后回顾中，你的团队试图找出哪里出了问题，哪里做得对，以及两者之间的一切。假设迈克是主要的随叫随到的人，但可怜的迈克刚生完孩子，累得连闹钟都没响就睡着了。Jose是一名开发人员，他醒来后在黑暗中跌跌撞撞地走向他的电脑，阅读了警报并打开了监控工具。他很快意识到数据库抛出了数百个异常。从来都不是好事。最初，Jose认为某些配置不正确。

一定是配置问题。这是一个很好的猜测。他继续深入研究这个问题，同时向别人寻求帮助。Jose能够访问显示数据库活动激增的图表，并将其与应用程序在同一时间内所做的更改进行了比较。啊哈!只是开玩笑。从来没有那么容易。是吗?

这是线索。最近的每笔数据库交易，她都有相同的文章ID。事实证明，一篇特别极端的文章的评论超出了数据库最初规定的限制。立即解决的办法是将限制设置得高得不可思议，直到早上运营团队能够正确启用自动伸缩。在事后审查期间，一些相关的开发人员注意到数据库中没有存储唯一性约束。开发团队的时间被分配到下一个sprint中，以允许重复的权利。这个地图，这个革命性的模型，为内部和外部涉众(包括面向客户的、非技术同事)提供了理解任何给定过程的必要上下文。在解释延误和事件，复杂的挫折时，它更有力量。我相信未来10年的技术将专注于开发者体验。

如何更好更快地发展?是的，但我们如何让它更令人愉快呢?服务提供者如何在不夸大简单性或混淆可观察性的情况下抽象复杂性。我们如何创新，不仅仅是在我们的技术上，还有我们如何建模?我迫不及待地想听听您对这种新模型和软件交付方法的看法。我很高兴看到它如何改变和适应我们在软件开发中面临的场景，以及每个角色和每个组织的工程师如何定制它以满足他们特定的约束和挑战。我相信这只是我们开始的革命。非常感谢你们邀请我。