Как стать автором
Обновить

4 часа и ни минутой больше: тактика и стратегия Uptime

Время на прочтение 7 мин
Количество просмотров 4.9K
Всего голосов 13: ↑13 и ↓0 +13
Комментарии 10

Комментарии 10

Мне кажется, что брать наутбук в пятницу в бар не очень хорошая идея)

Дежурный всегда имеет возможность подмениться, а вообще - профессионализм не пропьёшь )

Надеюсь вы это написали ради шутки.

Если вы оплачиваете сотрудникам on-call дежурства, то для того кто на этом дежурстве был и о каком баре в пятницу не может быть и речи.

Сотрудники достаточно взрослые, чтобы принимать ответственные решения. Если он пойдёт в бар - я не в праве ему это запретить. Но это не значит что он безответственно подойдёт к своей работе (например, будет употреблять алкоголь).

Речь о том, что есть достаточно гибкие возможности для обеспечения непрерывности с помощью дежурств, при этом без признаков «дежурного рабства».

пока у нас нет необходимости в создании круглосуточной системы дежурств в офисе, например, полноценного SRE — это экономически необоснованно.

А почему вы не считаете то, что описали, полноценным SRE? Судя по описанию кто-то у вас в офисе всё же круглосуточно, а все необходимые инженеры готовы прибыть/подключиться, когда угодно. Даже из бара :)

В целом, все так, но риски у on-call все же выше, чем у on-site :)

Своё железо и ЦОД это требование бизнеса или технически тоже сегодня оправдано на ваших задачах?

Это исторически, но за это время мы научились иметь аптайм в хорошем цоде лучше чем предлагают классические российские (а даже и зарубежные) IaaS. Плюс для бизнеса важно было снижать риски по ФЗ-152 поэтому рассматривали всегда только российские площадки (даже учитывая необходимость только локализации ПДн).

Сейчас мы активно смотрим и пробуем PaaS/IaaS — на рынке (сейчас речь про российский рынок) стали появляться достойные решения, думаю следующая моя статья будет об опыте миграции в облако :)
Спасибо за интересную статью. Подскажите пожалуйста насколько это возможно, как вы производите мониторинг сетевой инфраструктуры? Собираете телеметрию с помощью snmp или уже streaming telemetry? Продукт самописный или купленный\опенсорс?
Используется два подхода:
1. Классический snmp. Каждая железка опрашивается по полной, в том числе на ошибки на портах, температуры и тп. Также на ключевых каналах настроен ip sla udp-jitter. Все это собирается через PRTG. Сам PRTG уже алертит либо в мессенджер в каналы инцидент-группы, либо в Opsgenie для автоматики.
2. syslog. на всех железках включен кастомный сислог, в том числе на accounting по всем изменениям в конфиге. Все это в реальном времени экспортируется в SIEM, которая по правилу «все кроме явно исключенного» алертит в те же мессенджеры и опсжени + есть правила корреляции для ИБ.

+ heartbeat из интернета (из того же опжени) на случай если сеть вообще умерла и не позволяет мониторингу отправить об этом сообщение.

Для того чтобы достучаться до цода в случае полного падения сети есть отдельный защищенный сетевой менеджмент контур, с выделенным отдельным интернетом, фаерволом, впн и moxa подключенная консолью ко всему железу в стойке ядра.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий