大家好！ 我叫Alexander Afenov，是Lamoda订单处理团队的团队负责人。 今天我想告诉大家我们如何获得支持。
首先，让我们讨论一下它如何嵌入到我们的流程中以及总体上我们如何计划工作，冲刺和迭代。
然后，我将告诉您支持的来源以及支持的类型。
我将分享我们团队内部如何处理每种类型的支持的经验。
最后，我们考虑并总结了所使用做法的利弊。
我的团队现在有两个系统。 首先是一件大而可怕的事情，称为“
订单处理” 。 这是一个使订单从创建过程到交付（或退货）的生命周期自动化的系统。
该服务在PHP 7上旋转，并包装在Docker中，由Kubernetes精心组织，但同时在Zend1框架和Symfony 2的各个部分上实现。 对于其余的内容，我将解释Zend1是一个框架，该框架在一年半之前就已经寿终正寝了。 它不再受支持，甚至没有安全补丁。
该项目很大（超过15万行代码），它的工作很多。 例如，不仅处理订单，而且由于某种原因发送邮件，短信，推送，将数据传输到其他系统。 因此，我们将其分为单独的微服务。
我们从整体中带出的第一件事就是所谓的
退款工具 。 他是我团队的第二项服务，负责自动将钱退还给客户
（更多信息见我同事的报告） 。
尽管退款工具具有现代化的技术栈，但由于订单处理的遗留问题，它仍然产生了很多支持。
发生这种情况的原因是，我们采用了一定的业务流程，该流程以前是基于许多excel文件构建的，然后将其转移到可以通过Kafka工作的新系统，并且还可以与几个系统进行交互。 当然，在引入新系统并更改业务流程时，我们得到了支持。 多年来，我们已经获得了一些经验。
我认为人们分为两类：具有能够产生支持的生产系统的人和该死的骗子。 因此，我将分享对优化流程有用的经验。 如果建议的解决方案（组合解决方案或单独解决方案）适合您，那么将有更多的时间用于开发系统功能，分析技术积压工作，而不是与支持人员一起工作。
讨论使用的工具需要上下文，因此首先我们将讨论最基本的工具。
流程和角色
我们如何获得支持，在冲刺中占什么位置？
比例桶就是我所说的桶 。
我们从技术积压订单中提取10％的资金，这样它就不会停滞不前，也不会无限期地积累。
冲刺的大约20％是为了减轻风险。 例如，某人正在执行任务，但是此人“被公共汽车撞了”。 下一个将不得不重新检查上下文。 结果，我们将无法参与评估，并且一切都会变得很糟糕。
接下来，我们计划提供支持。 也就是说，我们已经知道有些问题。 这不会燃烧太多，我们将对其进行修复。
但是最有趣的是计划外的支持。 也就是说，我们假设某些东西在迭代期间可能会破裂，并且我们将花时间进行维修。
其余30％是项目。
您可能已经注意到结果超过100％。 这是由于我们总是尽力做到更多。 有时我们成功，有时不是很成功。
主要支持参数
我们根据以下参数对每张支持票进行评估：
- 业务的重要性 。 这对他们有多重要，这对业务流程有多大影响？
- 服务水平协议 问题需要多长时间才能解决？
- 优先权
如果我们系统的用户出了点问题，他们会向支持服务报告此情况，并说明事件部分或完全阻塞了业务流程。 支持立即给负责任的系统带来了新的麻烦，并将它
放在优先位置 。
关键程度和优先级是不同的术语。
优先类型阻止程序 -某些东西绝对破坏了一切，从而停止了业务。 未创建订单，不交付订单，不接受付款等等。
专业是次要的，可以修复更长的时间，因为有替代方法。
琐碎的 例如，某人写道我们的按钮颜色不愉快，应重新粉刷。 这样的票证极有可能永远不会发行。
还有诸如
服务级别协议之类的东西，它由支持服务以及系统的团队和业务所有者共同建立。 他们会查看哪些业务细分作为特定投诉的一部分。 例如，如果停止创建订单（在线商店的主要面包），那么此问题将具有较高的优先级，我们称之为P1。 P是重中之重，团结是最重要的。
P1是SLA的一种，这意味着我们必须在半小时内解决问题，最多只能在几个小时内解决。
P2的重要性不那么重要，我们必须花几个小时来决定。
P3-P4已损坏，不需要紧急维修。 您有一天可以做到，将其带入下一个迭代。
在这里，我们谈到了团队设定的优先级。 这可以是技术专家，高级支持工程师-处理问题的任何人。
假设我们当前有4个主要业务优先级的任务。 团队中的人，由于他的专业知识，会设定一定的数值，我们称之为
详细的优先级 。 基于此，将来会对支持板进行分类。 也就是说，在业务的最顶部将有最高优先级的任务，这些任务仍根据团队对任务的重要性和完成速度的理解而排列在内部。
在主要参数中，似乎最重要的一个缺失是-
正常描述 。 通常，我们的支持任务是从Sentry系统开始的，那里出现了错误，异常等。 一个人看到有一些小问题，便在吉拉（Jira）上产生了困惑。 由于我们的系统彼此集成在一起，因此任务跟踪器中会出现一个任务，在该任务的描述中只有一个指向Sentry的链接，而标题中有一个错误文本。 仅此而已。
得到这项任务的人应该如何处理呢？ 不太清楚。 如果您对此任务添加了良好的说明，则将极大地帮助您并节省时间。
谁将耙平一切？
当所有这些都完成后，就会出现一个问题：谁会整理这份精美的待办事项清单？ 答案是：支持工程师。
您可以在TeamLeadConf 2018的我的报告 “技术抵押：团队领导者和角色”中详细了解支持工程师是谁以及他的工作。
支持工程师是一个从支持待办事项中承担并修复最高优先级任务的人。 由于所有内容都经过精心整理，因此我们认为最重要，最紧迫和最“烘烤”在顶部。 如果没有任务，那么他可以进行技术积压。
他还在做什么？
1.
尝试找出并消除根本原因 ，即支持的根本原因。 当您定期定期收到相同类型的门票时，值得考虑为什么会发生这种情况。 最有可能在某个地方解决了一个问题，从而停止了类似任务的执行。
2.
设置校正和监视任务 。
如果支持工程师最多在一两天之内不能解决问题，那么他将为此设置一个单独的任务，该任务将进入开发积压工作。 然后由团队进行评估，并作为计划的支持进入迭代。
监控对我们至关重要。 我们不仅将监控挂起，用于持续监控的指标，还添加它们以定位运行时间最长的问题。 我认为，如果我们进行了不必要的监控，然后再喝下去，那会比以越来越多的票证不断地重复这个问题更好。
3.
寻找自动化的原因 。
示例 ：我们将数据传输到我们的系统，该系统可以使交付服务的工作自动化。 有时，事实证明，即使使用死信通道和转发，我们也无法在那里传递信息。 结果，这样的订单挂在某个地方，需要重新发送。
这是一个典型的支持，每周要进行几次。 为了解决此问题，我们决定使用“重新发送订单列表”按钮制作一个单独的页面。 我们不再有这种支持。 也就是说，他们认为是自动化的，将其提供给支持服务。
支持工程师的角色每周移交给另一个人-这是前提。 长时间进行这样的工作是压力，动力和衰退，因为您不断地修理某些东西，而不会给系统带来任何新东西。
规律性是恩典的源泉
似乎很明显，但是无论如何它经常被人们遗忘。 为了使一切正常运行，有必要将我们的流程投入使用并定期进行监控。
积压检查如果没有人在那儿，我们将在哪里获得精美分类的支持积压订单？
以一种很好的方式，您需要每月运行一次，并以琐碎的状态（很可能永远不会实现）关闭任务。 对自己和客户诚实。 如果由于此类任务导致的积压将无限增加，那么以后您将不得不惊慌以尝试关闭它们。 这不是很好。
详细优先权附加这是我们评估任务的关键程度的过程。 这样便可以进行正确的排序，支持工程师将从上方执行正确的任务。
争夺优先权例如，他们为您设置了一个任务，然后说：“伙计们，月度报告没有上传。 我们需要在一周内拿到它，但是它不起作用。 请修复它。 优先级P1。 您需要在2-3个小时内做出决定。”
然后您问：“严重吗？ 你们在说什么 毕竟，有一个星期要修复它。 让我们降级到P2，我们将有几天的时间。”
有时人们认为我们不会承担这项任务，因此他们将其放在特别重要的位置。 但是它发生了，反之亦然。 例如，他们给我们写信，未创建订单，并将P2优先。 这个问题更加严重，因此值得将P1的优先级提高。 有意识地在两个方向都讨价还价很有用。
建立新任务之前，我提到了Sentry系统，其中包括客户已经承担的任务。 但是，我们自己预计会出现问题，并自己将任务提交此积压中。
SLA性能监控为此，我们有时间表来显示我们有任务，这些任务的时间很快就会到期。 似乎这些难题首先是有道理的。
支持工程师支持
成为支持工程师是一个令人沮丧的过程，因此，一个人应该提供帮助。 我们怎样才能使他的生活更轻松？
将角色转移到团队的下一个我们需要保持时间表，确定谁将在下周进行此操作。 但是，会出现边界力矩。 例如，某人在星期五接受任务，而没有时间完成任务。 他下周可能会花一些时间，但是最好将任务交给新的支持工程师。 如果拖延积压耙两个星期，那么这个人很可能会很沮丧。 您将在下次个人会议上看到此内容：)
帮助找到问题的根源人们喜欢仅完成任务，但并不专注于找到根本原因。 值得提出一个问题：“如果您关闭任务，那么为什么最初会出现问题？”。 这种做法将有助于找到原因，消除原因，并有可能在将来摆脱这种支持。
需要“新鲜的外观”如果某个人在一定时间内无法获得可见的结果，则应将此任务转移到另一个任务上。 其他人将能够从另一端看问题，这可能以另一种方式解决问题。
但是，这种方法可能隐藏了一些有趣的心理方面。 就是说，从一个人那里接一个任务交给另一个人，您可能会冒风险说他知道得更多，所以他会应付。 最好以不同的方式呈现这些东西。 关注
我们所有人都需要解决系统问题的事实
，而不是相互证明我们哪个更酷。开发自动化工具那些经常成为支持工程师的人了解到，他们已经无法执行相同的典型任务。 最近，我们的一位开发人员在Go上拥有了自己的微型框架。 他进入不同的数据库，收集数据，在Kafka中推送内容。 因此，他能够尽可能地自动化该任务，并使他人的生活更轻松。
支持来源
有这么多的支持，我们有时甚至不考虑它的来源是什么？
稳定新系统和流程如果您带来了新的东西，那么很可能会错误地使用它。 您将自己遇到新的问题，并且您的支持积压订单将立即获得票证或票证的补充。
支持旧系统例如，我们的巨石。 正如我们总是在添加，重写他中的某些内容一样，他不能停滞不前。 当然，这会导致创建新的支持。
技术故障例如，网络断开连接。 您似乎不应该受到指责，但他们一定会来找您，并问为什么不创建订单。 有必要修理，修理，修改某些东西。 将需要手动干预，因此，积压中将提供新的凭单。
人为因素我们有一个案例，有人可以在RabbitMQ中产生一条消息，表明我们的消费者挂断了电话，并且一切都停止了。 在过去的7年中，这从未发生过，但是在某种程度上，它可以解决:)
导致失败的人为因素有人说“我现在要解决”，他从正在计费的服务器上拉出了硬盘。 结果，我们得到了我们所得到的。 这不是Lmoda的经历，而是我实践中的一个真实案例。
支持类型
分析请求当他们定期询问数据库中某物的状态时，他们会要求上载，收集一段时间的报告，等等。 这有点烦人，因此您有充分的理由考虑自动化，只提供用户界面或研究公司的结构。
例如，我没有立即发现我们拥有的大多数订单数据都存储在D＆A部门的Oracle数据库中，并且所有数据都可以从那里获得。
此类支持可以通过界面实现自动化，也可以转移到分析部门。
数据变更请求情况不同且不可预测。 假设我们的客户要用卡付款。 快递员到达时，他改变了主意，决定以现金付款。 或者，例如，在某个地方存在需要自动解决的自动化问题，我们需要更正此数据。
为此，我们尝试创建新的API句柄，创建接口，并最大程度地从开发和运营团队中删除这些任务。
这是一种危险的做法，我们会通过界面和API改进来摆脱它。维修业务流程如果直接需要编辑数据库中的某些内容，则存在错误的业务流程。 这可能是由于与IT相关的原因，或者是业务中出现了问题。 那里和那里都需要调整。
在这种情况下，您需要联系业务客户并讨论是否可以通过其他方式完成，或者要求开发以修复业务流程。
功能X停止工作这是我最喜欢的支持类型，因为它是最容易理解的。 也就是说，产品中有某种东西，但是它坏了，需要修复。 找出释放的原因和死因。 修理并关闭车票。 一切都很简单。
但是还有另一个支持
功能-X不起作用 。 它看起来可能像同一件事，但是换句话说。 但是，事实并非如此。
在这种情况下，他们来找您，说这件事不起作用。 您花了一两天的时间进行整理。 直到后来您才意识到
这在这里从未奏效 。 它只是不在您的系统中。
换句话说，当有人狡猾地想以支持任务的名义提出功能请求时，我将这种支持称为“狐狸”。 这是一个很痛苦的常规故事。 如果您不停下来，那么结果表明您的支持工程师或您自己正在引入新功能，而支持积压中的实际问题仍未解决。
重大事件
这只是棺材和泥炭大火的故事，当时IT系统中的故障严重到导致特定业务流程出现的地步。
从我们的实践中进行案例研究：由于代码错误和不完善的自动测试，我们开始向外部快递服务发送有关订单状态的特定说明，因此人们无法在取货点取货。 它影响了成千上万的客户。 我们必须取回所有订单，在上面花钱。 我们无法出售它们，并且失去了客户忠诚度。 这是一个严重的事件，已经伤害了企业。
值得以特殊的方式来处理这些事情，我将告诉您我们如何做。
如何找出正在发生的事情？行业中最常见的选择是向
用户学习。 他当然是最糟糕的，因为这意味着他们已经“烘烤”了。
他们看到没有任何适合您的东西，因此迫切需要修复。也许您会从支持服务中找到服务，该服务将监视监视并通知系统值班人员。但是最好的部分是通过监视的存在独立地找出来。也就是说，您可以使用按指标跟踪动态的系统。例如，如果在悬浮的电视上有东西变成红色，则说兔子死了。很酷，但这似乎还不够。如果您监视某些趋势，即使在途中也会遇到许多问题。。我们有这样的情况，当我们在监视器上注意到，Rabbit MQ集群的内存消耗在早晨开始增长时。我们知道那里只有16 GB，而在几小时内发生这种动态变化，内存将结束，一切都会下降。
由于我们看到了这种趋势，所以我们及时感到震惊。原来，我们挂了一个铲子插件，内存在流动。解决了问题，同时避免了重大问题。如果已经发生了什么，并且您找到了答案，则需要以某种方式进行本地化并发布。当然，根据团队的规模和正在做什么，您可以做不同的事情。但是我认为，动员非常重要。假设您的团队中有5个人。其中一个人分析了为什么现在什么都不起作用，而其余四个人继续削减其功能。结果，您的系统已损坏，还有许多新功能。这很酷，但是有时候动员和安排头脑风暴是值得的。对每个团队成员进行检查可以减少无用的时间。在他们设法解决所有问题之后，回顾阶段开始了。
回顾性
在Lamoda的本次会议上，我们有一名人员负责该事件所涉及的每个系统。如有必要，业务人员会出席，有时甚至还会有CTO来。在这次会议上，我们描述了到底发生了什么以及它在哪个系统上取得了成功。接下来是最有趣的时刻-分析动作顺序。也就是说，如果可能的话，我们在检测和灭火之间进行了最近的一分钟。
我们看到在13.05，呼叫中心收到了投诉。到大约13.13时，很明显它很大。只有在14.50，团队才开始执行任务。在此之前，由于某些原因，尽管设置了任务并通知了团队，但1.5个小时很简单。似乎可以减少1.5小时内的差距，从而在此事件上节省数百万卢布。为什么会出现这个问题？伙计们刚起身去吃饭，却不带笔记本电脑和手机，所以没有空。似乎在这一刻值得修复。例如，随身携带笔记本电脑，如果有重大问题，请离开值班人员。您还可以看到该修复程序已在16.55投入生产，这也很奇怪，因为在此之前已超过40分钟。当一切似乎都经过检查时，您可以滚动，但我们没有。为什么会这样呢？我们已经运行集成测试很长时间了，大约半个小时。在这种情况下，您需要做出决定。或者您推出更正后的系统并提出问题，或者创建一个新系统。或者，您正在等待超长的CI / CD流程滚动，并且发行版将投入战斗。显然，在我们的案例中，我们需要减少运行所有测试所需的时间，以便在检查完所有内容后更快地运行测试并加快滚动速度。下一点是影响评估。。影响是此事件对企业的影响。就是说，公司损失了多少订单，卢布，鹦鹉-没关系。这是您可以用来开展业务的图，它显示了如果IT没有给稳定，测试自动化之类的时间的话会发生什么。然后是预防措施的措辞。这很重要，因为您需要以某种方式向自己，管理层和其他任何人保证，今晚，明天等等不会发生同一件事。也就是说，您无需重复同一事件。为此，我们制定了预防措施。也就是说，您将如何实现这一目标，如何保护自己免受或期待它。还必须放下截止日期/修复版本。然后控制执行。计划是好的，但是避免问题更为重要。我认为，同样重要的是要记住，通常的支持不会比重大事件更糟。您可能会遇到一个严重的错误，整天或更长的时间忙碌起来，沿着同样的草原走走，了解为什么会发生这种情况，以及为什么要花这么长时间才能决定将来如何避免这种情况。使用相同的模式，您可以更有效地获得普通支持，这不适用于重大事件。水下利弊
可以理解，支持的存在会影响工作流程。它使人分心和生气，因为通常每个人都想删除新功能。但是，相反，您必须获得这些Augean马s的无数支持。另一方面，当一个人获得常规支持时，他设法感觉到系统中最不同的部分，因为支持是由关键而非业务流程构成的。这使您可以快速增加系统的专业知识。一直在哪里得到它？最初的答案是-不清楚在哪里。的确如此，因为这在很大程度上取决于每个特定的业务。Lamoda由几位常务董事组织，其中一位负责IT。他能够向负责业务其他部分的其他董事总经理解释说，如果我们创建具有自己的自动化和内部开发功能的服务提供商和在线商店，那么重要的是必须学习如何就业务与IT部门之间的互动进行大量谈判。他还设法传达出，他不应该尝试在新功能中填充80％的sprint，从而没有时间进行稳定，支持或提出问题。他能够做到这一点并取得成果。但是，我知道并不是每个人都有那么远。这就是为什么我相信，如果我们采用回顾性方法来获得认真的支持，那么仅由于IT部门没有足够的资源和时间来解决内部问题和获得支持，就可以向企业展示有多少资金投入了。
甜蜜点
我相信，如果应用这些方法，则可以更轻松地预测问题的出现并消除其根本原因，并且通常，停止踩到相同的耙子，然后达到一个非常有趣的状态。在这种情况下，每种新型支持对您来说都是新的。这听起来可能具有讽刺意味，很有趣，但实际上却很有价值，因为您将了解自己并不会一遍又一遍地解决相同的问题。我希望你能成功。