Как сделать, чтобы ИТшка работала надежно

Границы применимости

Любое изделие имеет свои границы применимости. Например, ручная отвертка применима при работе вручную. Оторвав от нее ручку и воткнув в дрель - шуруповерт не получится. Отвертка будет сломана, да и вряд ли даже один винт получится закрутить таким приспособлением. С ИТ-решениями тоже самое - нужно знать их границы применимости и применять в рамках этих границ. Основные очевидные границы, которые существуют для каждого приложения:

Максимальный допустимый используемый объем данных. Не важно, о чем речь - об Excel, которым пытаются открыть очень большой файл, или о целой информационной системе, использующей десяток баз данных. Идеально масштабируемых решений не бывает (даже в теории).

Максимальное допустимое время непрерывной работы.

Да, и о софте это тоже (к сожалению). У софта тоже есть проблемы, связанные с непрерывной работой - утечки памяти и другие проблемы реальны и их следует признавать. Очень хороший софт способен работать без ограничений по времени. Его очень мало.
И о серверном (и любом) железе это тоже. Длительная работа без перезагрузок и выключений приводит и к накоплению статических зарядов, которые портят RAM (в первую очередь), и к температурным эффектам в полупроводниках. Перезапуск сервера - основа его долгой службы. Правильно выстроенная архитектура приложений и серверная инфраструктура позволяют перезагрузить любой сервер без какого-либо эффекта на работу для клиентов в целом.

Максимально допустимая нагрузка. Очевидно, но она должна быть известна в численной величине до начала работы с пользователями, чтобы своевременно реагировать на близость к ее достижению.

Количество ресурса, которое потребляет определенный пул пользователей. Например: приложение потребляет 4 CPU, 8 GB RAM, 25 GB SSD, а его БД потребляет 8 CPU, 32 GB RAM, 100 GB SSD на 1000 пользователей. Рост в пределах первых 10 тысяч пользователей ожидаем линейный.

Качество установки и настройки

Качество установки и настройки определяется простыми факторами:

Переживает вкл/выкл. Полностью все серверы и оборудование можно выключить кнопкой питания, включить и всё заработает после включения само, без каких-либо действий людей.

Любой один сервер переживает вкл/выкл. Его можно выключить, включить и после включения заработают все системы на нем, и все системы, зависящие от его работы, сами, без каких-либо действий людей.

Любое приложение, контейнер, сервис, виртуалка или "железный" сервер получая высокую нагрузку, выше его допустимых границ, после её снижения начинает работать штатно без вмешательства людей сам.

Любое приложение, контейнер, сервис, виртуалка или "железный" сервер запускаются автоматически после падения. Что-то упало - должно автоматически включиться само без действия людей и функционировать после этого штатно.

Вопросы, которые стоит задать Админу/SRE/DevOps

Вопрос

Хороший ответ

Плохой ответ

Когда произойдет ближайшая аппаратная авария, которая не заденет работу сервиса?

Мы тестируем всё оборудование до ввода в эксплуатацию, этим исключаем брак. Ближайший выход из строя предполагается SSD диска в течение 5и лет. Он находится в RAID и это не заденет работу сервиса, но потребует замены.

1) "ЦОД может упасть в любой момент"

Такой вариант ответа выходит за рамки ответственности Админа/SRE/DevOps, а сам он ушел от ответственности за работу в его зоне ответственности.

2) "Мы не знаем когда сломается железо, давайте у нас всего будет в двойном запасе."

Ответ ниже уровня компетенций, позволяющих построить надежную систему.

Когда произойдет ближайшая аппаратная авария, которая заденет работу сервиса?

Материнские платы служат 5-8 лет в штатном режиме в условиях эксплуатации ЦОД. За всё время наше оборудование не было перегрето ни разу, эксплуатируется год в условиях ЦОД - ближайший отказ сервера по причине проблем с МП произойдет минимум через 4-7 лет. Мы можем заранее вывести из работы этот сервер, чтобы предотвратить аварию и произвести замену.

"Мы можем сделать отказоустойчивый кластер и маловероятно, что он откажет целиком".

Такой ответ говорит о непонимании причин отказа оборудования - скорее всего одинаковое оборудование, работающее в идентичных условиях, будет отказывать в близких временных интервалах. Вероятность выхода из строя серверов кластера одного за другим - это максимально вероятный сценарий.

Вторая часть некорректности заключается в том, что сами системы отказоустойчивых кластеров на уровне логики отказывают чаще, чем конкретное оборудование.

Когда произойдет ближайшая логическая авария, которая заденет работу сервиса?

Наша СУБД увеличивается на 500GB в год, текущее свободное место на хранилище под ней - 1TB. Через 2 года место под БД закончится и это приведет к остановке сервиса. Мы можем заранее произвести работы по увеличению хранилища или масштабированию СУБД на разные хранилища.

1) "Мы не знаем когда возникнет баг в софте".

Такой ответ говорит о том, что опыт эксплуатации конкретного софта недостаточен для оценки его надежности.

2) "Мы будем быстро исправлять такие ситуации, наймем дежурную смену и т.п."

Такой ответ говорит о непонимании внутреннего устройства обслуживаемых систем, отсутствии возможностей прогнозировать ситуацию и желании закрыть неизвестность человеческим ресурсом.

Если мы вырастем по количеству пользователей в 5 раз, сколько нам нужно будет ресурсов добавить?

Ответ представляет собой таблицу из сервисов, потребление ресурса которыми вырастет, и величины, на которые оно вырастет, исходя из расчета, опирающегося на границы применимости.

1) "Сейчас у нас 40 CPU, 100GB RAM, 5TB диска. Давайте умножим на 5".

Ответ не несет в себе смысла - это может быть как верно, так и нет в любую сторону по любому из параметров. Далеко не факт, что все системы вырастут линейно.

2) "Давайте наращивать ресурс последовательно".

Ответ говорит о том, что нет расчётных границ применимости в отношении пользователи/ресурсы, а значит при работе сервиса с каждой итерацией роста мы будем внезапно упираться в потолок ресурса. Вероятно, что рост в такой ситуации может быть нелинейным.

Итоги еще рано

Это одна из статей цикла об управлении ИТ и внутри ИТ. Будем писать и дальше о том, как добиться предсказуемой работы, надежности, скорости и удобства для пользователей. В общем всего того, что пользователи любят, а сделать это для них должны администраторы, sre, devops и другие участники команды эксплуатации инфраструктуры.