День сисадмина приходится на последнюю пятницу июля. Это как раз сегодня. Вопреки представлению, что сисадмины распутывают провода и чинят разъемы, это вообще не так. В действительности это киты, на которых держится весь интернет. Давайте вместе с hoster.by разберемся, кто такие сисадмины на самом деле и какие задачи решают каждый день.
В этот момент Тед Кекатос решил создать специальный день, в который пользователи могут благодарить системных администраторов. Устроил небольшой пикник на окраине Чикаго. Это пришлось на 28 июля 2000-го — как раз последняя пятница июля.
Тем временем системы и интернет стремительно развивались, а технологии усложнялись — уже требовалось больше сисадминов с большим набором компетенций. Сегодня системные администраторы — золушки компьютерной индустрии, которые обслуживают компьютеры, поддерживают серверы, спасают работу целых отделов и защищают важные данные компаний. Своего рода хранители сети. Как скажет сисадмин, такой жизнь в ней и будет. Или не будет.
Что по задачам? Ежедневно сисадмины:
помогают настраивать и запускать веб-приложения и сайты
разбираются с работой сайтов
выясняют, почему корпоративная почта не отправляет или не принимает письма
определяют и исправляют ошибки из-за неправильных настроек приложения или кода (самые частые — ошибки 400 и 500)
проектируют и запускают информационные системы по запросу клиента
разрабатывают и строят высоконагруженные отказоустойчивые кластеры приложения и баз данных
внедряют в инфраструктуру DevOps-практики и инструменты
проводят аудит сервера, информационной системы, указывают на узкие места и проводят работы по их устранению
отражают DDoS-атаки и делают так, чтобы минимизировать их в будущем
устанавливают систему мониторинга и резервного копирования
проектируют и реализуют улучшения для сервисов — облака, виртуального хостинга, почты, сети и так далее
автоматизируют процессы и конфигурации инфраструктуры
бекапят все, что могут, и бережно хранят это
Дано: в hoster.by обратился клиент, крупный интернет-магазин. Со стороны бизнеса все шло отлично — проект активно развивался и рос, набирал обороты и клиентскую базу. Но что касается инфраструктуры — она достигла своего потолка и уже не справлялась с объемами, которые требовались для стабильной работы бизнеса. По предварительной оценке решением могло стать горизонтальное распределение нагрузки.
Решение:
При анализе инфраструктуры обнаружили, что архитектура, на которой работал магазин, в принципе не создавалась под работу в горизонтально масштабируемом кластере. Это значит, что нужно было построить абсолютно новую серверную архитектуру для работы этого приложения.
Оценка сложности проекта показала, что надо работать в синергии, так как придется копаться не только в серверной части, но и в программной, коде.
Собрали команду. С одной стороны — рабочая группа на стороне hoster.by во главе с сисадминами, с другой — специалисты на стороне заказчика. Пообщались и расписали план работ по Scrum.
Начали разработку отказоустойчивой схемы кластера и системы балансировщиков нагрузки. Разработка на стороне заказчика взялась за переписывание кода под новый принцип работы. В это время наши сисадмины занимались построением высоконагруженного отказоустойчивого кластера баз данных.
В процессе получили еще одну задачу, которая была важна для бизнеса. Надо было сделать так, чтобы нагрузка распределялась в зависимости от количества запросов, что особенно актуально на время распродаж. Для этого разработчики меняли логику работы с базами данных, а системные администраторы выстроили кластер БД, который отвечал всем необходимым требованиям. В результате приложение могло читать и записывать данные на любой сервер в кластере в любой момент.
Итого: переписали архитектуру под возможность быстрого горизонтального масштабирования кластера для естественного роста проекта. Также реализовали возможность быстрого добавления дополнительных ресурсов на время крупных распродаж. Например, «Черной пятницы». В итоге выстроенная система приобрела гибридный вид — часть находится на физических серверах, а часть — динамически подключается при необходимости из облака hoster.by.
По сложности этот проект 10 из 10.
Дано: крупная компания обратилась к нам, чтобы перенести свою инфраструктуру в облако.
Решение:
Взяли техническое задание и изучили его на предмет необходимых ресурсов и требований к обеспечению безопасности.
Сразу поняли, что одного лишь облака будет недостаточно. Надо не просто перенести инфраструктуру в публичное облако, а конкретно в этом случае будет целесообразно построить индивидуальное приватное облако. Оно даст монопольные ресурсы, закрытую инфраструктуру и полное сопровождение технической части нашими сисадминами, что и закрывает все запросы и потребности клиента.
Приступили к построению приватного облака. Для этого под конкретно этот проект подобрали все необходимое оборудование. Выстроили сеть для частного облака с полным дублированием интерфейсов и сетевого оборудования, чтобы в случае обрыва или выхода из строя одного из коммутаторов все продолжало работать.
Конечно не забыли про отказоустойчивость на уровне виртуальных машин и общее хранилище для важных документов.
О ситуации на рынке креативных коммуникаций и резонности фестивального движения в 2020 году рассказала Алена Устинович,
