你好 我叫Vitaliy Kostousov，我在Global Tech Heroes团队工作，今天，我将向您介绍支持-任何服务中最重要的组成部分。 您可以使用精美的图片，有时甚至是在开玩笑的聊天机器人来制作出色的应用程序。 您可以公开转储，首先为客户提供低成本服务。 您可以雇用一个绝妙的SMM邮箱，您不会为此感到羞耻，并且他们不必像90年代的会计师那样经常被更换。
但是，如果没有对您的服务的健全支持，这一切都可能会失败。 并在全球范围内提供支持-从解决用户问题到确保软件和硬件的功能。 好吧，很严重，人们会使用这种应用程序多久了，这种应用程序已经愚蠢了几周，而开发人员仍然没有对问题做出正常反应，该支持服务没有提供自动应答，并且可以在呼叫中心免费收听古典音乐几个小时？
我们如何安排一切，我们在工作中使用什么来发现问题并解决问题，我们中有多少人以及其他一切都处于削减之中。
现在我们在3个国家/地区工作：俄罗斯，英国和以色列，我们有数十万活跃用户，仅企业客户就超过20,000，每天都有对我们应用程序的需求。 并且有驱动程序和来自他们的请求。 以及内部系统和监控。 所有这一切都应该工作，并且运作良好。 为此，我们有一个称为“技术英雄”的全球技术支持团队-研发团队，升级操作员和工程师以及全球事件经理。 这就是他们在工作中面临的问题。
团队和用户
立即做出预订，我们团队的最终用户不仅意味着优先的客户和驾驶员（私人和公司），还包括市场营销，支持服务和我们的内部部门。 当然，他们写信来支持使用该应用程序或在社交网络上提供支持。 如果问题是技术性的，那么SalesForce内部的任务将立即交给我们。 他们不仅可以撰写有关应用程序及其整体或某些功能的工作质量的文章，还可以撰写公司内部服务的性能的文章。 Gett员工有1000多人，他们询问有关工作软件，流程组织的问题。
我们的团队由分布在三个国家（以色列，英国和俄罗斯）的8人组成。 俄罗斯的一位专家进行远程工作，他的职责包括与运营流程一起工作：监视和更改我们的主要服务。 剩下的七个涉及运营问题，以及更多其他问题：测试，错误，规范，快速解决来自运营专家和经理的电话，并监视我们的所有数据库，服务和微服务。 该团队处理来自所有到达国家的所有门票。 在大多数情况下，您必须处理局部问题，但是碰巧在全局服务的工作中存在一些严重的错误，然后工作进入了全局模式。
您还需要考虑到我们在全球范围内拥有许多b2b客户-该系统具有非常灵活的设置，并且有可能与公司的服务进行业务集成。 也就是说，汽车的类别比服务的私人用户要多得多。 重要的是要了解所有这些都会影响服务的操作和事务性操作的数量。 B2B细分受众群可以使用公司网站上的个人帐户。
软体类
市场上已经有几种使用票务的系统已被证明是有用的：LiveAgent，ZenDesk，ZohoDesk等。 您可以根据方便进行选择，可以摆脱习惯，可以-从与同事一起使用的软件开始，以免阻塞一堆层层的拐杖（也必须得到支持和完成）。 因此，我们为SalesForce工作，因为它已被公司的主要运营领域（销售和支持）使用。 这使您可以从案例创建者的角度跟踪每个案例的状态。 系统会根据上诉主题自动确定案件的优先级。 SalesForce也集成在Jira中，如果创建了任务或在开发中引入了错误，则在案例中还将显示其状态。 这就是我们实现支持与开发之间透明通信的方式。
SalesForce，可点击专用的应用程序系统使您可以跟踪到达我们的每张机票的SLA。
门票和要求
具体来说，我们的团队致力于应用程序本身（针对驾驶员和乘客），操作专家与之合作的微服务以及测试和监视的工作。 此外，总会有新的报告和监视请求，这可能对其他部门的同事很有用。 同时，如果某些监控仅与服务和数据库的技术参数有关，则这些监控仅适用于我们的团队。 监视的一部分会向我们，负责的团队和支持发送警报。 例如，如果问题与驱动程序的应用程序连接，则支持将更快地响应并在必要时通知驱动程序。 因此，信息的时间减少到几分钟。
监控方式
我们有很多监控。 无论是newrelic（启用系统服务），grafana（监视特定方案），datadog（基础架构正常运行时间），只要其中一个起作用，我们都会立即在Slack中收到通知，并依次收到呼叫（感谢pagerduty）。 并在一定时期内任命了一个人。 由于此操作是自动发生的，因此该特定人员当前不可用或根本没有应答，则该呼叫将沿着链进一步转发。
触发警报后，我们将重新检查系统性能，并找出故障原因（或负载增加，或大量事件或呼叫，将在此处发生）。 如果我们知道这是一个问题并且需要解决，我们将致信给专门的运维小组，以供运营专家使用。
因此，我们始终在线。
事件管理
如果您的公司提供服务，则事件管理无处可寻。 我们根据以下方案工作：
- 及时发现问题。
- 通知负责人问题。
- 各个级别的利益相关者通知。 也就是说，我们谈论的是业务问题，以便那里的每个人都确切了解此类问题如何影响公司和利润。
- 保持最大的工作透明度。
- 强制性根本原因分析。 毕竟，这是问题的根源，可以防止下一个问题。 这比第二轮再次解决它更快，更有用。
目的是了解零阶段的问题。 这是您作为提供工作能力的员工发现问题的时候。 当客户通知您有关她的信息时，不是这样。 因此，我们积极使用APM（应用程序性能监视）工具包。 我再给他们讲一次。
新遗物- 监控我们所有的微服务和网关
- 50x，4xx错误
- 紫杉
- 数据库数据库
NewRelic，可点击格拉法纳 事件监视（使之清楚地知道是什么完全停止了工作或行为与正常情况不同）。
Grafana，可点击数据狗 监视我们系统的硬件组件（数据库，负载平衡器）。
DataDog，可点击气刹 应用程序/微服务的代码异常（例如，在数据库中执行代码或查询时出现异常的列表，如果出了问题并且在列表中，我们将对其进行跟踪）。
Kibana-监视微服务/应用程序日志（驱动程序/客户端）。
因此，所有内容不仅适用于检测，还适用于及时通知（立即，越快越好），所有这些都与许多通知渠道（从Slack和
PagerDuty到良好的旧电子邮件通知）相关。 因此，整个团队将立即了解任何异常情况。 警报可以发送到不同的渠道。 对应用程序运行至关重要的监视始终将警报发送到技术支持团队，并有选择地发送到负责特定功能/服务的开发团队的渠道。 所有这些都有助于优化响应时间。
下一步出现了困难，当发现问题后，您必须迅速通知负责服务的人员。 如果有很多流程和微服务，这并不是一件容易的事，这意味着负责任的流程也不少。 当您需要任何提示时，警报可能会在深夜到达，但您只是不分清谁对什么负责。
因此，我们创建了一个方便的目录，列出了所有服务所有者（通常是整个公司）。 如实践所示，仅此一项就帮助我们将解决每个事件的时间减少了约20％。
在这种情况下，进行中的灾难的最佳解决方案是让事件无人负责。
有一个特别的人，全球事件经理，他是严重事件的中枢。 他致力于监视和更改基本系统，以消除可能导致业务骨干的错误，并负责公司的高级管理人员，向他们提供有关根本原因分析的详细报告。
因此，简而言之，事件管理过程本身看起来像这样：
- 我们确定事件的原因。
- 我们找到负责人。
- 我们正在与他协调努力，以尽快解决问题。
- 在事件发生期间，我们将做出所有必要的决定。
- 我们将此告知企业，将所有问题带给他们。
- 当灰尘散落时，我们开始进行根本原因分析RCA（根本原因分析）。
我们正在Jira中构建事件报告，有一个相应的模块
Incidents ，我们在那里添加了许多其他字段。
RCA只有三个阶段。
1.初始RCA这是问题原因的顶层描述（无论是数据库，基础结构还是代码问题）。 该报告由管理该事件的支持人员准备。 该报告必须在事件完成后的24小时内完成。
2.研发RCA该过程中最重要的部分必须在事件完成后的48小时内完成。 已经对根本原因进行了完整的技术分析-发生原因，为何未发现原因（测试人员被忽视或没有适当的监视），是否有可能再次发生，以及如何防止再次发生。
3.行动在第二段的基础上，形成了相应的子任务，事件保持打开状态，直到这些子任务中的最后一个关闭。 没有人希望此任务长时间使用看板，因此可以激励您更快地解决所有问题。
这就是我们Gett处理事件的方式。
人物与技术
当然，我们的工作水平为24/7，SLA为99.99％。 我们在GoLang / Ruby上拥有的主堆栈，这为处理复杂算法提供了必要的速度。 总共有150多个微服务，而且它们都在GoLang和Ruby上。 我们使用MySQL，Postgres和Presto作为数据库。 我们在AWS上有存储。
在我们的服务中，最严重的负担是在新年假期和前两周。 竞争者的状况也影响，例如，其中之一放弃了应用程序，这意味着我们的机器将被更频繁地调用。
内部工作中也有一些高峰会影响最终用户。 例如，当我们更新数据库或在供应商和供应商方面执行技术工作，或部署新服务进行生产时（不是在星期五，是的），或者我们委托立即影响大量用户或交易的功能。
我们也是人，有时会发生错误的设置或手动干预导致操作错误的情况，因此我们针对这种情况制定了一个计划：
不，不是那样。 在这里：
- 我们检查服务，日志和审计中的数据。
- 我们在Scrum上测试并执行更新操作。
- 我们为团队准备任务，并在生产中监视任务的执行。
如果您对任何细节感兴趣，请随时在评论中提问，我们将在这里或在单独的详细帖子中回答。