哈Ha！ Alexey Pristavko再次与他联系。
与我以前的文章不同，今天我们将讨论人。 今天的英雄是我所代表的运营服务和开发服务。
这些服务的协调工作是成功启动创建的服务并使其顺利“飞行”的关键。 但是，正如我（不仅是）的经验所表明的那样，几乎没有任何项目不能没有冲突和分歧，而冲突和分歧是无辜的服务。
在本文中，我将尝试回答以下问题：
- 开发方法和流程如何影响运营？
- 是什么驱动冲突的各个方面？
- 引起分歧的根本原因是什么？
欢迎来到猫！
服务面临的挑战是什么
我们将更好地了解部门，并从运营服务（它也是一种支持服务）入手。 为什么需要这种可怕的野兽，它执行什么任务，以及“为谁服务”？
运营服务的主要任务是
管理服务级别，即在SLA框架内维护IT系统的运营。
在与客户（通常与企业）达成协议的框架内，运营应提供对服务及其正确功能的持续访问。
这是此问题的解决方案：
- 事故管理：在事故中恢复业务功能；
- 问题管理：解决事故和事件的可能原因；
- 配置管理：收集信息并分析软件和基础架构运行参数；
- 变更管理：将变更过程中出现问题和事故的风险降至最低。
开发服务的作用也是可以理解的-最初创建IT服务，并应客户要求将新功能引入其中。
当然，您已经对开发人员和支持人员的摩擦点有所怀疑，因为在任务交叉的地方存在冲突。 但不要急于下结论。 开发人员和管理员之间永恒的争论距离“战斗”的中心还很远。
分歧在哪里增长
程序员和管理员的“战争”不是人类利益的对抗，而是服务的对抗。
问题在于这些服务的优先级和动机。 以其最一般的形式可以描述如下：
- 开发团队希望使用最新鲜的技术（专业发展，兴趣）并尽快进行工作（外部动力）。
- 该操作感兴趣的是最稳定的技术（它们的问题是已知的并且已被普遍接受的解决方案），以及在开发的软件中出现问题时应采取的措施的详细说明（加快故障排除速度的外部动机）。
同时，重要的是要理解，不仅开发人员“看到”了新功能，而且并非总是由管理员引起的。
- 管理员积极参与开发过程-参与构建基础结构，容错和可伸缩性方案，准备初始配置以及理想地参与准备软件需求的过程。 所有这一切都称为解决方案开发过程（不要将其与直接代码编写相混淆！）。
- 程序员积极参与了这一行动。 他们纠正软件错误，执行系统优化和技术改进以符合SLA系统，即解决最终IT服务的可访问性问题。
程序员和管理员之间的冲突
源于概念的替代：从专业角度（而不是从功能角度）倾斜从属结构总是会导致冲突。 通常，管理员和程序员在完全不同的团队（有时在部门中）工作，并且分别以操作和开发为动力。
结果，来自开发部门的程序员被“强迫”修复了旧的错误，或者，上帝禁止，编写文档，对此感到不高兴。 运作中的管理员也很愤慨，他们被要求迅速投入一架三角钢琴为开发人员筹集新服务器或向他们提供建议。
各方都不认为这是问题的共同解决方案，而是对自己任务的分散注意力，即使没有这一目的，这也是不可见的。
但是我们决不能忘记客户，因为客户虽然间接地还是冲突的参与者。 通常，他需要获得稳定的稳定服务。 裸露的代码，即使是最好的代码，对于系统外的客户也完全没有用。 他基本上对世界有不同的看法：
标准客户没有创建，编写或抱歉执行的任务。 客户希望使用魔术按钮“一切顺利”来解决业务问题，而IT部门则
强力提供特定的解决方案。
让我们看一下冲突的各个方面：
当然，这只是功能和操作要求中最常见的部分。
因此，我们发现冲突仍然存在
三个方面：开发，运营和客户。 而且，在很大程度上，客户是团队的“发起人”，在团队之间分担责任。 这本身并不是一件坏事，如果不是为了普遍接受的团队和团队之间责任的分离，那将是一个可控的冲突。
但是我们已经知道，这两种服务都不是自给自足的。 它们被“服务”障碍隔开，同时，它们不仅必须根据产品生命的各个阶段在责任转移领域彼此互动，而且还必须积极参与解决彼此的问题。
客户影响力的另一个方面是他的业务发展策略和方法。 在这种情况下，我说的是不了解开发特定IT解决方案的过程。 在没有这种理解的情况下，顾客经常要求将猫做成鲸鱼，然后将翅膀附在它上面。 而且总是紧急的。 有时，这可以通过情况和思想的创新来证明是正确的；有时，这是争夺市场领导者和草率复制的结果。 原因可能大不相同，但结果却是其中之一。
问题在于这种策略会转化为不断的实验，并且需要在尽可能短的时间内获得结果。 这种方法使我们陷入持续发展的深渊，而不是针对特定结果的工作。 原则上，最后一个问题是由企业架构师解决的，但是下午您将找不到这些人。
开发过程
最终，我们几乎达到了一切准备就绪的地步。 服务运营的关键是什么？
- 改进的透明度。 要管理变更，您需要了解变更的内容，方式和原因。
- 有关工作和维护逻辑的文档。 理想情况下，采用指示形式。 遵守SLA的关键不仅在于可靠性，还在于对所有执行者都应该掌握的操作方法的清楚理解。 “口头知识”在这里并不适用-人们经常轮流工作，因此不可能收集所有信息并解释所有内容。 在压力很大的情况下（而事故总是在压力下）的记忆可能会失败。
- 明确的转移程序以支持新版本，并测试其操作特性和功能的正确操作。 以简单的方式-回归和压力测试。 新功能的简单功能在最小程度上激发了操作的乐趣：开发团队将自行修复失效的保修版本。 但是在旧功能中引入的错误，如果不能自行消除，那么操作应该至少是过程，有时甚至证明了开发的罪恶感。
- 有机会将您的需求转移到新项目的工作。 这是最重要的运营特征所在。 例如，如果软件不知道如何在群集中工作，则该操作将无法独立使其真正可靠。
我们弄清楚了什么是运营服务，以及为什么开发人员如何对某人重要。 让我们继续进行最有趣的部分-我们将分析各种开发方法及其对运营服务的影响。
让我们从经典开始：瀑布模型。
瀑布
Waterfall致力于提供完整和复杂的功能。 发行模型是循环的。 这个周期从几周（极其罕见）到四分之一零六个月。 几乎总是有需求的一致性集合，需求分析，解决方案体系结构的开发，持续时间的评估，计划以及最后的全面回归测试。
遵守运营利益取决于具体的实施方式。 由于通常会突出显示必要的阶段，因此该过程涉及考虑转移到运营的所有要求和正式程序，包括文档。
客户面临的主要问题是迭代的持续时间和发布后的长期稳定性。 有时，客户被迫等待几个月才能在产品中出现需要一周创建的产品。
如果结果超出预期，则客户将不得不忍受直到新周期结束，甚至两个周期结束。 定期提供操作服务。 技术功能通常是最后一个。
每次较大的发布都伴随着一堆错误，这些错误会在稳定期间消除。 通常，这对所有各方来说都会变成地狱-开发被迫从事剥削，操作接受事件，并以各种方式将其开发“推”为保修解决方案，而客户则一头雾水，一头雾水。
尽管如此，从操作的角度来看， Waterfall是您可以集成的最统一和可预测的方法论过程。 通常，既不关注周期的持续时间，也不关注操作的稳定性。 两次发行之间的时间越长，您可以冷静地工作的时间就越长-这始终是一个加号。 此外，如果有信心在接下来的六个月内什么都不会改变，那么将您的工作输入到流程中就容易得多。
不幸的是，很多时候客户都反对Waterfall并要求加快项目的开发。 为了这个愿望，诞生了更灵活的方法。
敏捷的
如您所知，Waterfall是很长的时间，从形式上讲需要大量文件，
每个人都经常在上面作弊 。 客户立即需要一切。 为了解决这些问题，程序员提出了一个敏捷清单：
●人员和交互比流程和工具更重要。很难与此争论。 当然，人是更重要的。 但是不要忘记这些过程。 它是标准化和规范交互的过程。 此外，只有在公共场合，您才能走得更远。 至少，人们喜欢生病，放松身心，有时喜欢戒烟。
●有效的产品比全面的文档更重要。这也是事实。 但是还有另一个问题：如果没有文档，该产品将运行多长时间？ 很可能不是很长时间。 但这是好是坏-由于缺乏来源，因此无法解决。 然后，您将必须遵循许多人都爱上的策略：“我无法弄清楚-从头开始重写。” 但是它总是很长，很昂贵，而且通常结果不会更好。
●与客户的合作比谈判合同条款更为重要。再说一次，是的，更重要。 但是，如果没有在合同条款上达成协议，我们将如何理解以及如何做呢？ 除了如何通过明确定义的文件进行沟通和达成共识之外，还有哪些其他方法可以克服相互的误解？ 当然，合同也不是万能的，但它比90年代的方法可靠得多：
-Vasya，你了解我吗？
-好吧，兄弟。
●进行更改的准备比遵循原始计划更为重要。但这仅在一种情况下是正确的：如果最初的计划是完整的日志，以及他们计划要构建的内容，那么事实证明没有人需要。 您全力以赴地为企业架构师服务！
盲目遵循此宣言的结果是，业务客户本人必须转变为企业架构师（但通常，他变成南瓜）。 这不仅不是他固有的“功能”，还必须了解IT。
Scrum
Scrum是使Waterfall适应敏捷清单思想的最早尝试之一。
Scrum的主要特点：
- 短距离冲刺。 冲刺开始后的组成不被编辑；
- 通过将个人用户故事放在冲刺愿望日志中进行规划。 在项目所有者上-从“项目日志”中选择；
- 客户的利益由项目所有者（产品所有者）代表；
- 开发团队由不同领域的专家组成：程序员，开发人员，架构师，分析师。 团队对整个结果负责；
- 我们将整个团队的日常讨论替换为文档和信函。
从理论上讲，这是一种相当健壮的方法，并且在许多方面都类似于瀑布的微型版本。 在实施阶段开始出现问题。 不幸的是，由于SCRUM的周期较短，因此即使在sprint计划阶段，也导致将整个功能分解为单独的部分，并按部分交付功能。 由于这个原因，我对任何事实都保持沉默，因为在“比赛”期间一切都已经出错了。 短距离的冲刺不会留出时间管理股票，这变得极其困难。
由于不断完善其最终形式的功能的优先级，它很快就会投入生产。 另外，在编写UserStory的阶段，要评估计划的功能对最终系统的影响是极其困难的，因为在此功能出现时，它的状态是事先未知的。
这如何威胁剥削？ 尚不总是清楚什么应该起作用，什么不应该起作用，如果它起作用了，那么什么时候起作用。 因此，由于正常回归将花费大量时间，因此将系统测试替换为功能测试。 这会给产品增加错误，并延迟解决方案。
对于正常操作，操作应：
- 参加SCRUM会议；
- 不断了解开发的工作情况；
- 了解开发计划和发布状态。
否则，将不可能花时间接受或发表评论。 当然，遵循所有这些要点的剥削是极为罕见的，如果这样做的话，则会导致冲突升级。 甚至在SCRUM会议期间的产品所有者也可以在短时间内忽略支持的兴趣。
看板
发展方法论发展的下一步是看板。 对于企业而言，已经很短的SCRUM周期似乎也太长。 您可以了解客户：您一直想成为第一个获得最酷芯片的人。 是的，更改计划的效率很低，结果“开销”太多了。
因此，正如建筑商所说，“就地雕刻”更加容易。
看板是日本精益生产方法的IT实施。 但是有一个细微差别：在丰田汽车中，使用看板的汽车是由预先设计的零件组装而成的，而开发则主要是设计。 在编程中，零件功能只是简单地复制；不需要不断地“生产”它们。
看板通常与CI / CD流程并驾齐驱。 这里没有冲刺，任务在准备就绪时会连续交付，此类任务的大小受到严格限制。 因此，几乎无法交付完整形式的复杂功能，因为它不适合任务的大小。
在这种情况下，系统文档实际上在编写之前就已经过时了，并且失去了所有意义，因为不可能修复已生产（即已生产但未开发）系统的某些状态，而在该状态下，系统将是正确的。
对于操作而言，这意味着无法提供SLA：没有文档，也没有人知道系统如何工作以及应该如何工作。
SLA实施的基础是可预测性和连续操作的保证。
但是，采用这种方法时，通常没有运营服务，只有开发团队会因维修而定期（有时）因“技术债务”而分心。 但是没有人为此担心，因为计划不会中断。 很难破坏没有的东西。
正如原始过程的作者所规定的那样，看板非常适合将计划替换为对刺激的操作。 例如，这就是处理事件的方式-如果发生故障，我们将对其进行修复。 在大多数情况下，通过已知程序。 但是，看板完全不适合开发，因为它很难暗示最终结果。 这种方法的选择将使您注定要经历一个无休止的过程-“我们已经建立，正在建立并且仍在构建”。 不要那样做！
开发者
当然，DevOps本身并不是一种开发方法，但是我不禁插入了5个戈比，而不是谈论解决操作与开发冲突的最常见尝试。
从理论上讲，DevOps是一组旨在使开发专家与信息技术专家进行积极互动以及他们的工作流程相互融合的实践。
DevOps基于紧密的软件开发和运营相互依存的思想，旨在帮助组织快速创建和更新软件产品和服务。 关于快速创建和更新。 但是利用这些问题根本不存在。
结果，DevOps成为通过完成必要的开发链接使开发团队独立于运营服务的一种手段。 显然，此解决方案本身是单方面的，并且仅解决了一方的问题-开发。 通常，这只会加剧冲突，使开发人员完全忽略服务操作。
实际上，我通常会遇到两种实现：
自动化管理员代替开发团队出现在开发团队中，以解决开发人员的问题。我认为很明显，由于他们的解决方案在测试环境中出现问题，我不想让工作效率高下，冲突只会加剧。- 同样的事情，但运营团队本着“没有人，没有问题”的原则被废除了。
管理服务可用性的任务顺其自然。出于决策动机的人根本不会留下。定期会出现一个DevOps工程师团队，但这并没有任何改变，因为他们领导的优先级是发布的发布日期。只要没有人看到，其他所有任务都可以推送。即使我们回到原来的想法，即DevOps而是关于测试，并且它应该保证迅速转移有保证的质量变化，但再次证明，不可能从流程中排除或替换操作。这个想法本身的重点恰恰在于确保变更过程的质量并保证这些变更的质量。请注意，SLA合规性和访问控制未在任何地方提及。变更（组件）的高质量并不能保证整个系统的高整体性能。不可能预见一切并验证一切-测试不能保证不会发生事故。设备可能会磨损，在意外条件下运行期间系统可能会发生故障。最后，还有人为因素。因此，即使有DevOps团队，操作过程也是必不可少的，并且无论如何都需要文档。当出现问题时，您必须弄清楚它是如何工作的。代替输出
那么该怎么做以及如何成为？业务：为您的产品制定一致的开发策略并管理市场状况，而不是急于应对变化。开发：不要将客户变成企业架构师。他不是建筑工程或IT系统的专家；他是某些本地业务领域的专家。综上所述：摆脱操作服务的尝试很可能会成功，但是您不太可能放弃操作流程本身，可访问性应该受到控制。您可以决定由专职的专业人员来管理，还是对开发人员造成额外负担。DevOps是提高质量的极好和有用的方法，但是由于上述原因，它也将不能保证任何事情，也无法替代成熟的运营服务。这种方法不会解决开发，运营和业务之间的冲突，但是将有助于确保持续的接受过程并减少总体压力。当然，你们所有人都以一种或另一种方式参与了上述情况和过程。在评论中分享您的经验！