哈Ha！ 十年来，我一直在支持Highload IT系统。 我不会在本文中撰写有关将Nginx配置为在1000+ RPS模式或其他技术条件下工作的问题。 我将分享对此类系统的支持和操作过程中出现的问题的看法。
监控方式
技术支持不会等到应用程序到达并显示内容“
为什么为什么……该站点再次关闭？”。 网站崩溃后的一分钟支持应该已经发现问题并开始解决。
但是这个地方只是冰山一角 。 它的可用性是最早要监视的之一。
当网上商店的剩余商品停止来自ERP系统时，情况又如何呢？ 还是为客户计算折扣的CRM系统已停止响应？ 同时，该站点正在运行。 有条件的Zabbix获得200响应。 值班没有收到任何来自监视的通知，并愉快地检查了《权力的游戏》新赛季的第一集。
通常，仅通过测量内存，RAM的状态以及服务器处理器的负载来限制监视。 但是，对于企业而言，在网站上获得产品可用性更为重要。 群集中一台虚拟机的有条件丢弃会导致流量停止流向该虚拟机，其他服务器上的负载也会增加。 公司不会亏本。
因此，除了监视服务器上操作系统的技术参数外，还需要配置业务指标。 直接影响金钱的指标。 与外部系统（CRM，ERP等）的各种交互。 一定时间内的订单数。 成功或不成功的客户端授权以及其他指标。
与外部系统的交互
任何年营业额超过十亿卢布的网站或移动应用程序都可以与外部系统进行交互。 从前面提到的CRM和ERP开始，到将销售数据传输到外部大数据系统以分析购买并向客户提供他肯定会购买的产品（实际上没有）为止。 每个这样的系统都有其自己的支持。 与这些系统的通信经常会引起痛苦。 尤其是问题是全球性的，并且您需要在不同的系统中进行分析时。
某些系统将电话或电报交给管理员。 您需要在某些地方给管理人员写信或去这些外部系统的错误跟踪器。 即使在一个大公司的情况下，不同的系统也经常在不同的应用程序记帐系统中工作。 有时无法跟踪应用程序的状态。 您将在一个有条件的Jira中收到一份申请。 然后，在第一个Jira的注释中，您将链接链接到另一个Jira中。 在应用程序的第二个Jira中，已经有人写了一个注释，
您需要致电条件管理员Andrei来解决该问题。 依此类推。
解决此问题的最佳方法是，例如在Slack中创建一个单独的通信空间。 邀请所有参与外部系统操作的人员参加。 以及单个跟踪器，以免重复应用程序。 从监视警报到显示产品中的错误，应在一个地方对应用程序进行监视。 您会说这是不现实的，而且在历史上发生过，因此我们在一个跟踪器中工作，而在另一个跟踪器中工作。 出现了不同的系统，他们拥有自己的自治IT团队。 我同意，因此需要从CIO或产品负责人的层面上解决问题。
与您交互的每个系统都应提供具有明确SLA的服务支持，以优先解决问题。 如果条件管理员Andrey有时间为您服务，则不会。
男人-瓶颈
项目（或产品）上的每个人是否都有这样的人，他们的休假导致当局抽筋？ 它可以是devops工程师，分析师或开发人员。 毕竟，只有一名devops工程师知道哪些容器上安装了哪些容器，在出现问题的情况下如何重新加载该容器，而实际上，如果没有它，就无法解决任何复杂的问题。 只有分析师知道您的复杂机制是如何工作的。 哪些数据流流向何处。 在什么样的参数要求提供哪些服务，我们将收到答复。
谁会迅速了解日志中为什么存在错误并快速修复产品中的关键错误？ 当然是同一位开发人员。 还有其他一些，但仅出于某种原因，他了解系统的各个模块是如何安排的。
这个问题的根源是缺乏文档 。 毕竟，如果描述了系统的所有服务，那么无需分析师即可解决问题。 如果devops从忙碌的日程中选择几天，并描述了解决典型问题的所有服务器，服务和说明，那么没有它就可以解决不存在的问题。 无需休假就可以在海滩上快速喝完啤酒，并寻求Wi-Fi解决问题。
支持人员的能力和责任
在大型项目中，公司不会为开发人员支付薪水。 他们从类似的项目中寻找昂贵的中间人或前辈。 在支持下，情况略有不同。 他们正在尽一切可能减少这些成本。 公司正在招聘昨天的低成本enikeyshikov并大胆地投入战斗。 当涉及到Zelenograd某家工厂的名片站点时，这种策略是可行的。
如果我们谈论的是大型在线商店，则每个小时的停机时间所花费的成本超过管理员的平均月薪。 起点为年营业额10亿卢布。 这是
2018年TOP-100评级中所有在线商店的最低营业额。 将该金额除以每年的小时数，得出的净损失超过100,000卢布。 而且，如果您不计算夜间时间，则可以放心地将其增加一倍。
但是钱不是主要的，不是吗？ （不，当然是主要的）仍然存在声誉损失。 著名的在线商店衰落的时间可能会引起对社交网络和主题媒体出版物的评论浪潮。 朋友在厨房里的对话风格是“不要在那里买东西，他们的站点一直在下降”，根本无法进行测量。
现在负责。 在我的实践中，有一种情况是值班管理员没有及时响应，通知监视系统该站点无法访问。 在一个宜人的夏季星期五晚上，莫斯科一家知名在线商店的网站静静地摆放着。 在星期六早上，该网站的产品不了解为什么该网站无法打开，并且在Slack中的支持聊天和紧急警报中都保持沉默。 这样的错误使我们损失了六位数的费用，而这位值班人员也工作了。
责任是一种很难发展的技能。 一个人有没有。 因此，在面试中，我尝试通过各种问题来识别其存在，这些问题间接表明一个人是否习惯承担责任。 如果一个人因为父母这样说而选择了大学，或者因为妻子说他没有什么收入而换了工作，那么最好不要与这样的人打交道。
与开发团队的互动
当用户在操作过程中遇到产品上的简单问题时，支持人员会自行解决。 它尝试重现该问题，分析日志等。 但是，当产品上弹出错误时该怎么办？ 在这种情况下，支持将为开发人员启动任务，并从这里开始乐趣。
开发人员经常超负荷工作。 他们正在创建新功能。 通过销售课程修复错误，说不是最有趣的。 完成下一个冲刺的截止日期已到。 然后令人不快的人们从支持者那里说：“紧急放弃一切，我们有问题。” 此类任务的优先级很小。 尤其是在问题不是最严重且站点的主要功能正常运行，并且发行管理器运行时眼睛鼓鼓并且没有写以下内容时：“紧急将该任务带到下一个发行版或修补程序中。”
具有正常或低优先级的任务从发行版到发行版。 对于问题“何时完成任务？” 您将收到以下格式的答案：“很抱歉，现在有很多任务，请团队负责人或发布经理。”
产品上的问题比创建新功能具有更高的优先级。 如果用户不断遇到错误，那么糟糕的评论不会让您等待。 恢复受损的声誉非常困难。
开发与支持之间的交互问题由DevOps解决。 该缩写通常用作帮助创建开发测试环境，构建CI / CD管道并在生产中快速显示经过测试的代码的特定人员。 当过程中的所有参与者彼此紧密互动并帮助快速创建和更新软件产品和服务时，DevOps是一种软件开发方法。 我的意思是分析师，开发人员，测试人员和支持人员。
此方法的支持和发展在其目标和宗旨上并不相同。 开发涉及运营，反之亦然。 分布式团队的著名用语：“问题不在我身边”在聊天室中并不常见，最终用户变得更加快乐。