你好，哈布尔！ 我支持 Highload IT 系统已经有十年了。 我不会在本文中写有关设置 nginx 在 1000+ RPS 模式下工作的问题或其他技术问题。 我将分享我对此类系统的支持和运营过程中出现的问题的观察。
监控
技术支持不会等到内容为“为什么......网站无法再次运行？”的请求到达。 网站崩溃后一分钟内，支持人员应该已经发现问题并开始解决它。 但该网站只是冰山一角。 它的可用性是最先受到监控的之一。
网上商店的剩余货品不再从ERP系统到达时怎么办？ 或者为客户计算折扣的 CRM 系统是否已停止响应？ 该网站似乎正在运行。 有条件的 Zabbix 收到 200 响应。 值班班没有收到监控的任何通知，正在开心地观看新一季权力的游戏第一集。
监控通常仅限于测量内存、RAM 和服务器处理器负载的状态。 但对于企业来说，在网站上获得产品的可用性更为重要。 集群中一台虚拟机的有条件故障将导致流量停止流向该虚拟机，并且其他服务器上的负载将增加。 公司不会亏钱。
因此，除了监控服务器操作系统的技术参数外，还需要配置业务指标。 直接影响金钱的指标。 与外部系统（CRM、ERP 等）的各种交互。 一定时间内的订单数量。 成功或不成功的客户端授权和其他指标。
与外部系统交互
任何年营业额超过十亿卢布的网站或移动应用程序都会与外部系统进行交互。 从上述 CRM 和 ERP 开始，到将销售数据传输到外部大数据系统以分析购买情况并为客户提供他肯定会购买（实际上不会购买）的产品结束。 每个这样的系统都有自己的支持。 与这些系统的通信常常会带来痛苦。 特别是当问题是全局性的并且您需要在不同的系统中进行分析时。
有些系统为其管理员提供电话号码或电报。 在某个地方，您需要写信给经理或访问这些外部系统的错误跟踪器。 即使在一家大公司的背景下，不同的系统也经常在不同的应用程序会计系统中运行。 有时无法跟踪应用程序的状态。 您会收到一个条件 Jira 中的请求。 然后，在第一个 Jira 的评论中，您在另一个 Jira 中放置了指向该问题的链接。 在应用程序的第二个 Jira 中，已经有人写了一条评论： 您需要致电条件管理员 Andrey 来解决问题。 等。
这个问题的最佳解决方案是创建一个单一的沟通空间，例如在 Slack 中。 邀请外部系统运营过程中的所有参与者加入。 还有一个跟踪器，以免重复应用程序。 应用程序应该在一处进行跟踪，从监控通知到未来错误解决方案的输出。 你会说这是不现实的，历史上曾发生过我们在一个跟踪器中工作，而他们在另一个跟踪器中工作的情况。 不同的系统出现了，它们有自己自治的IT团队。 我同意，因此这个问题需要从 CIO 或产品负责人层面来解决。
您与之交互的每个系统都应提供支持即服务，并具有明确的 SLA，以按优先级解决问题。 条件管理员安德烈（Andrey）有时间给你讲讲时就不行了。
瓶颈人
项目（或产品）中的每个人是否都有一个人去度假引起了上级的震动？ 这可以是 DevOps 工程师、分析师或开发人员。 毕竟，只有 DevOps 工程师才知道哪些服务器安装了哪些容器，出现问题时如何重新启动容器，一般来说，任何复杂的问题没有他就无法解决。 分析师是唯一知道复杂机制如何运作的人。 哪些数据流流向哪里。 根据对哪些服务的请求的哪些参数，我们将收到哪些响应。
谁能快速理解日志中出现错误的原因并及时修复产品中的严重错误？ 当然是同一个开发商。 还有其他人，但由于某种原因只有他了解系统的不同模块是如何工作的。
这个问题的根源是缺乏文档。 毕竟，如果描述了系统的所有服务，那么无需分析师就可以处理问题。 如果 DevOps 从繁忙的日程中抽出几天时间，描述解决典型问题的所有服务器、服务和说明，那么在他不在的情况下，问题就可以在没有他的情况下得到解决。 你不需要在度假时在海滩上快速喝完啤酒，然后寻找 Wi-Fi 来解决问题。
支持人员的能力和责任
在大型项目中，公司不会克扣开发人员的工资。 他们正在从类似的项目中寻找昂贵的中老年人。 有了支持，情况就有些不同了。 他们正试图以各种可能的方式降低这些成本。 公司雇佣廉价的昨天的 Enikey 工人并大胆地投入战斗。 如果我们谈论的是泽列诺格勒一家工厂的名片网站，那么这种策略是可能的。
如果我们谈论的是大型在线商店，那么每一小时的停机成本都超过了 Enikey 管理员的月薪。 让我们以年营业额1亿卢布为起点。 这是评级中任何在线商店的最低营业额 。 将此金额除以每年的小时数，即可得到超过 100 卢布的净损失。 如果你不计算夜间时间，你可以放心地将金额加倍。
但钱不是最重要的，对吧？ （不，当然是主要的）还有声誉损失。 知名在线商店的倒闭可能会在社交网络和专题媒体上引起一波评论。 厨房里的朋友们的谈话风格是“不要在那里买任何东西，他们的网站总是瘫痪”，根本无法衡量。
现在要承担责任。 在我的实践中，曾经出现过这样的情况：当班管理员没有及时响应监控系统发出的站点不可用的通知。 一个夏日的周五傍晚，莫斯科一家知名网店的网站静静地躺着。 周六早上，该网站的产品经理不明白为什么该网站打不开，Slack 中的支持和紧急通知聊天中一片寂静。 这样的错误让我们损失了六位数，而这名值班人员也因此丢掉了工作。
责任是一项很难培养的技能。 一个人要么有，要么没有。 因此，在采访中，我试图通过各种问题来识别它的存在，间接表明一个人是否习惯于承担责任。 如果一个人回答说他选择大学是因为父母这么说，或者是因为妻子说他收入不够而换工作，那么最好不要和这样的人交往。
与开发团队互动
当用户在使用产品过程中遇到简单问题时，支持人员会自行解决。 尝试重现问题、分析日志等等。 但是当产品出现Bug时该怎么办呢？ 在这种情况下，支持人员会将任务分配给开发人员，这就是乐趣的开始。
开发人员不断超负荷。 他们正在创造新的功能。 通过销售修复错误并不是最有趣的活动。 完成下一个冲刺的最后期限即将到来。 然后来自支持部门的不愉快的人过来说：“立即停止一切，我们有问题。” 此类任务的优先级最低。 特别是当问题不是最关键并且站点的主要功能正常工作时，并且当发布经理不会睁着眼睛到处跑并写下：“紧急将此任务添加到下一个版本或修补程序中。”
具有正常或低优先级的问题会从一个版本转移到另一个版本。 对于“任务什么时候完成？”的问题您将收到以下格式的答复：“抱歉，现在有很多任务，请询问您的团队领导或发布经理。”
生产力问题比创建新功能更重要。 如果用户不断地发现错误，那么差评很快就会到来。 声誉受损是很难恢复的。
开发和支持之间的交互问题由 DevOps 解决。 该缩写通常以特定人员的形式使用，该人员帮助创建开发测试环境、构建 CICD 管道并快速将经过测试的代码投入生产。 DevOps 是一种软件开发方法，流程中的所有参与者都相互密切交互，有助于快速创建和更新软件产品和服务。 我的意思是分析师、开发人员、测试人员和支持人员。
在这种方法中，支持和开发并不是具有各自目的和目标的不同部门。 开发涉及运营，运营涉及开发。 分布式团队的名言：“问题不在我这边”不再那么频繁地出现在聊天中，最终用户变得更高兴了一些。
来源： habr.com