На вызове Добро пожаловать в очередной выпуск «На вызове», пятничную колонку The Register, которая стремится улучшить состояние экосистемы технической поддержки, делясь историями читателей о том, как они вытаскивали сломанные технологии из пропасти.
На этой неделе мы встречаем читателя, которого мы назовём “Раулем”, который рассказал нам о своей прошлой жизни в качестве коммерческого консультанта по поддержке Linux.
«К нам обратились с просьбой провести проверку состояния их крупного сервера, на котором работало критически важное бизнес-приложение», — рассказал Рауль в «На вызове». Ему была отведена неделя на выполнение работы.
Клиентом была медицинская организация, а приложение, которое на нём работало, представляло собой сложный Java-веб-приложение, которое обрабатывало такие задачи, как планирование посещений, управление бронированием и даже платежи. Оно работало на виртуальных машинах, в базе данных Postgres, внешнем массиве хранения и на трёх серверах, один из которых был резервным для базы данных.
Приложение функционировало неважно.
«Во время пиковой нагрузки по утрам система зависала и становилась не отвечающей на срок до получаса», — объяснил Рауль. Медицинские специалисты, административный персонал и пациенты были вынуждены ждать, пока приложение проработает – ситуация, мягко говоря, нездоровая.
Когда Рауль прибыл для диагностики проблемы, он обнаружил, что сотрудники на месте ругаются друг с другом.
«Специалисты по виртуализации винили систему хранения, специалисты по хранению — приложение, а разработчики приложения — операционную систему», — сказал он. Отношения клиента с поставщиком приложения также были токсичными, поскольку кто-то из сотрудников медицинского учреждения оставил неодобрительные отзывы на форуме поддержки поставщика. После этого последовали угрозы судебным преследованием.
На следующий день Рауль прибыл как раз вовремя, чтобы увидеть, как приложение зависло около 10 утра. Он проверил сервер приложения — он был в порядке — но заметил, что сервер базы данных был очень загружен.
Рауль сохранял спокойствие и на третий день работы дождался, пока система снова зависнет.
«Я сразу же направился к серверу базы данных и увидел, что кто-то выполнял длительную задачу обновления, которая блокировала строки таблиц, что означало, что все остальные транзакции должны были ждать», — написал он.
Рауль покопался немного глубже и узнал, что поставщик приложения обнаружил ошибку в своих разработках и вносил исправления в базу данных на работающей системе, в рабочее время, не предупредив своего клиента.
«Я собрал доказательства, составил отчет и представил его руководству», — рассказал Рауль в «На вызове». «Разработчики приложения признались, что знали об этой проблеме уже несколько месяцев, у них было решение «почти готовое» и всё должно быть хорошо».
Рауль вскоре узнал, что ситуация была далека от “хорошей”, потому что в течение последних двух дней работы он решил провести проверку состояния базы данных Postgres.
«В производственной базе данных хранились медицинские данные, личная информация и осуществлялись платежи. В ней не было никаких средств контроля доступа, – сказал Рауль в «На вызове». “Она была настроена как «ВСЕ ВСЕ ВСЕ», так что любой пользователь на любой системе мог получить доступ к любой базе данных в качестве любого пользователя».
Это открытие заставило Рауля почувствовать себя плохо.
«Я чуть не свалился со стула, сообщил об этом руководству, а они сказали мне, что разработчики заявили, что это необходимая конфигурация, и они не беспокоятся», — написал он.
«Я ушёл домой с мыслью о том, чтобы никогда больше не пользоваться услугами этого поставщика», — заключил он.
Скрывали ли когда-нибудь от вас причину технической проблемы? Не скрывайте свою историю от “На вызове”! Нажмите здесь, чтобы отправить письмо в “На вызове”, чтобы мы могли поделиться вашей историей в следующую пятницу. ®
Автор – Simon Sharwood
