重新思考SDLC

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

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

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

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

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

所有的衍生作品都没有那么雄心勃勃，那么大胆，而是只关注软件交付的一部分。我认为，我们应该再一次为这个广阔的保护伞，这个整体的视角注入生命。我们面临的挑战是，DevOps是一个日益过时的解决方案来解决以前的问题。开发人员现在面临的文化和技术挑战远远大于如何更快地部署单片应用程序。云原生是未来，是默认决策的下一个集合，也是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能够访问显示数据库活动峰值的图表，并将其与大约同一时间应用程序的变化进行比较。啊哈!只是开玩笑。事情从来没有那么容易。是吗?

这里有个线索。最近的每一个数据库事务，她都有相同的文章ID。结果是，一篇特别偏激的文章的评论超出了最初为数据库提供的限制。立即的解决办法是将限制设置得高得不可能，直到早上运维团队可以适当地启用自动扩展。在事后审查期间，一些参与的开发人员注意到数据库中没有存储惟一性约束。在下一个sprint中分配开发团队的时间，以允许重复的权限。这个地图，这个革命性的模型，为内部和外部的涉众，包括面向客户的、非技术人员的同事，提供了必要的上下文来理解任何给定的过程。在解释延误、事故、复杂的挫折时，它甚至更有力。我相信未来10年的技术将会集中在开发者体验上。

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