Новая встреча DZ CLUB в Варшаве: лид Google о будущем мобильной индустрии. Купить билет 🎟
Support us

«Делай или молись». О чём говорили на Большой админской IТ-пятнице

Оставить комментарий
«Делай или молись». О чём говорили на Большой админской IТ-пятнице

Пока катастрофы, взломы, атаки и другие сетевые кошмары портят жизнь, надёжный бэкап и профессиональное комьюнити возвращают её радость и здоровый сон. 180 системных инженеров и архитекторов из 6 городов собрались на Большую IТ-пятницу в Минске, чтобы обсудить профессиональные проблемы и способы их решения, о которых не пишут в учебниках.

Организаторы включили в практическую конференцию 13 лучших докладов проекта «IT-пятница в hoster.by» по итогам года: от особенностей работы с катастрофами до построения отказоустойчивых сетей.

«Проще предупредить, чем лечить»

«С атаками на сайт, как и с простудами, гораздо проще проводить профилактику, чем лечить уже болезнь, — уверен директор по развитию hoster.by Павел Богданов. — Поэтому необходимо обновлять ПО (причем не только ядра CMS-сайта, но и всех модулей), чаще менять пароли и прочее бла-бла. Но в университете не учат, что при нагрузке на сайт и DOS-атаках нужно:

  1. Разделять сервер приложений и сервер баз данных — это первое, что помогает справиться с нагрузкой на сайт.
  2. Делать дублирование серверов приложений, чтобы нагрузка шла не на один сервер, а «тушилась» на разных.
  3. Дублировать сервера баз данных и настраивать их как «мастер-мастер».
  4. Подключать внешние firewall’ы — такие, как CloudFlare и похожие.
  5. Если сайт работает для аудитории в определенной стране, можно разрешить доступ только из этой страны — например, из Беларуси. Всему остальному миру сайт будет недоступен. Очень действенное средство».

«Если вирусы всё-таки заразили сайт — найти и удалить их специальным ПО: антивирусом ai-bolit или ImunifyAV. Стандартные антивирусы в такой ситуации не помогают», — резюмирует Павел.

«Вероятность ошибки можно просчитать»

«Системный администратор, как доктор, — считает Влад Шарпио, CEO в u-team. — Вероятность „націснуть не тое“ при 12-часовом рабочем дне возрастает до 36%». Статистика эта взята у врачей скорой помощи неспроста: «Системное администрирование — не творческая работа. Давайте будем честными: наши действия на 90% повторяются. Как и на приёме в поликлинике: осмотреть, проверить карточку, изучить анализы, назначить лечение».

Но человеческий фактор и, соответственно, вероятность ошибки можно просчитать: «в узких рамках устоявшихся рабочих процессов это реально. Есть даже формула: h *потенциал человека = (К опыт+К адаптации+К эскалации)*К темп работы*К утомляемости. Правда, любая формула — это самое большое упрощение».

По теме
Все материалы по теме

Чтобы проанализировать человеческий потенциал новых сотрудников и не ошибиться, во-первых, не стоит руководствоваться эмоциями и симпатией.  Во-вторых, «определить опыт сотрудника можно, обратив внимание на то, как часто человек обращается к внешней помощи при решении задачи. Адаптация максимально высокая, когда он справляется сам».

В-третьих, эскалация: сколько задач сотрудник передал соседу? «Параметр очень своеобразный, поскольку есть должности которые подразумевают большее количество эскалации», но всё же его можно использовать для оценки человеческого потенциала. Например, младший сисадмин должен делать сам половину дел. Старший — всё сам.

«Человек может быть интровертом и работать тихо. Может создаваться впечатление, что он — не часть команды. Но если посмотреть на показатели, то очевидно, что он просто меньше отвлекает других от работы и выполняет задачи максимально эффективно. У меня был такой случай. У сотрудника коммуникация была „на нуле“, но при этом все задачи он решал сам. Сейчас этот сотрудник — старший инженер крупного облачного провайдера».

  1. Расчёт человеческой ошибки/Human Error Assessment and Reduction Technique (HEART) 
  2. Человеческая ошибка (Теория ошибок) 
  3. Расчёт человеческой ошибки. Александр Мироненко, ITB Professional Services Team leader 

«Отличный способ улучшить ситуацию за небольшие деньги»

Об ускорении работы дисков рассказал системный архитектор hoster.by Иван Семерник: «В то время, как требования софта к железу растут, всё ещё очень много серверов с медленным storage на базе HDD. Если заменить их на быстрые SSD, это приведет к удорожанию услуг. Поэтому на данном переходном этапе [к SSD-only решениям] мы используем технологии кэширования: когда набор SSD-дисков небольшого размера неплохо ускоряет работу медленного и большого storage на базе HDD. SSD-кэширование — отличный способ за небольшие деньги улучшить ситуацию с хранилищем в системе. Таким способом можно ускорять не только чтение, но и запись. Решение эффективно работает для стандартных типов web-нагрузки».

«Главное — успокоиться и не пытаться самостоятельно спасти мир»

Если что-то сломалось, главное — не паниковать. «Ведь опыт админа растёт прямо пропорционально выведенному из строя оборудованию», — говорит ведущий системный администратор hoster.by Михаил Ходоренко.

Хорошая новость: если система построена правильно, выход из строя её 50% не должен приводить к остановке рабочего процесса. «Из опыта могу сказать, что любое построение отказоустойчивых решений говорит о том, что система должна быть построена по принципу n+1 — т. е. все узлы должны дублировать друг друга, и выход одного узла из строя не должен влиять на работоспособность всей системы. Но не всем нужна такая отказоустойчивость, которая тянет за собой повышенных расходы на оборудование и работу специалистов».

Плохая новость: в момент, когда происходит сбой, большинству админов тяжело сохранить самообладание. «Главное — успокоиться, провести анализ, выполнить необходимые действия. И не пытаться самостоятельно спасти мир. И если готовые инструкции не помогают, передать задачи (особенно сложные и нестандартные) более квалифицированным специалистам. Админу нужно прокачивать холодную голову, горячее сердце и чувство юмора — без этого никак».

«Поломки — это часть работы: не надо их бояться — к ним нужно быть готовым. Правильная подготовка и вовремя включенная «соображалка администратора» (опыт, знания и быстрота реакции) — это 90% решения. 

«Если резервные копии не делаются — идём в церковь, ставим свечку»

«Надёжный бэкап — условие здорового и крепкого сна сисадмина.  Если есть резервная копия, то можно быть уверенным, что вы потеряете минимальное количество данных при сбое и обеспечите быстрое восстановление работоспособности серверов и системы в целом. Ну, а если резервные копии не делаются совсем — идём в церковь, ставим свечку», —  ведущий системный администратор hoster.by Михаил Ходоренко знает, о чём говорит.

Куда делать резервные копии?
  1. На тот же сервер, где и база данных. Минус опции — копия может сгореть вместе с серверами.
  2. На выделенный сервер или в специализированное хранилище. Самый правильный вариант, но не поможет, если авария затронет всю стойку с серверами или дата-центр.
  3. В облачные сервисы. Их владелец гарантирует сохранность данных. Минус — время. Скорость поиска может быть очень ограниченна. «Все знают, что эти сервисы рассчитаны на то, чтобы данные заливали, а не забирали. Информация из облачного хранилища может быть получена весьма не быстро. Добавьте к этому зависимость от провайдера и  загруженность его каналов связи. Для дополнительного резервного копирования — хорошо, для основного — проблемно, так как из-за временного фактора можно не получить свой бэкап вовремя».
Бесплатные решения резервного копирования баз данных MySQL
  1. Копия файлами. В плюсах скорость, возможность сжатия и простота автоматизации. Среди минусов — полная остановка сервиса для консистентности данных, невозможность выполнить частичное резервное копирование и, как следствие восстановление, а также невозможность восстановить копию в неродном окружении.
  2. MysqlDump — встроенная утилита, универсальный формат хранения. Правда, у неё низкая скорость работы и при бэкапе и восстановлении она вызывает блокировку всей базы данных. «95% пользователей этой программы не знают, что для сохранения триггеров требуются дополнительные ключи».
  3. LVM-снапшоты — универсальная платформа для разных бэкапов, но тоже не без недостатков, среди которых, например, сложность выполнения и контроля разных этапов.
  4. Percona XtraBackup — сплошные плюсы: неблокирующий бэкап, сохранность полной базы данных, высокая скорость, контроль ситуации при выполнении копии. Однако, невозможность резервного копирования TokuDB.
  5. Slave and Bin Logs — а это вообще не бэкап. Для использования требуется понимание режимов репликации.
  6. Другие специализированные решения, «заточенные» под вашу инфраструктуру.

«Есть три типа админов: те, кто ещё не делает бэкапы, кто уже делает бэкапы и кто проверяет сделанные бэкапы на консистентность. Чем больше копий — тем спокойнее вы будете спать. И тем чище будет ваша совесть».

Никита Шинкевич, Effective Soft

Боль сисадмина:  «всё, что вы читали год назад, уже устарело»

Самый острый вопрос в профессии сейчас — куда развиваться? Оставаться в on-premise или переходить в облако? Я работал и в крупной enterprise on-premise компании, и в облачном провайдере. Могу сказать, что это два абсолютно разных мира. Технологии on-premise отстают от облачных решений на 2-3 года.

В on-premise инфраструктуре всё происходит очень медленно в плане получения новых интересных возможностей для бизнеса. Для внедрения нового продукта необходимо согласовать покупку нового оборудования, совместимого с новым продуктом, купить новые лицензии для продукта, настроить интеграцию с уже имеющейся инфраструктурой. Далее — сопровождение путем установки обновлений и дописывание необходимого функционала.

В «облаке» всё по-другому. Актуальные технологии уже там. И надо всего лишь заказать себе пробный период того или иного продукта, протестировать его и, если все подходит, оплатить.

На вопрос, оставаться в on-premise или переходить в облако, нет однозначного ответа. Здесь нужно продумывать все риски использования того или иного решения. Возможно  гораздо более удобным будет даже гибридное решение (когда часть ресурсов в облаке, а часть «на земле»). Но любое решение требует постоянного развития. Всё, что вы читали и изучали год назад, уже устарело. Оно никуда не делось, а создало надежный фундамент для изучения новых технологий и возможность быть конкурентными на рынке труда.

Советы от Никиты Шинкевича

1. Для начала советую почитать официальную документацию на сайте того или иного облачного провайдера: она там постоянно актуализируется и освещает новые решения.

2. Ознакомиться с медиумом или хабром — там публикуют статьи и решения от обычных пользователей.

3. Можно начать с курса по Google Cloud Platform. В нём освещены вопросы, часто пересекающиеся с облачными платформами других провайдеров.

4. Есть хороший автор Scott Duffy, который публикует свои курсы по Azure и периодически их обновляет.

5. На udemy есть ещё два автора — Ryan Kroonenburg и Faye Ellis. Они очень качественно преподносят информацию по облачной платформе AWS.


IТ-пятницы в hoster.by проходят каждый месяц в формате открытых встреч для системных инженеров, разработчиков, ИT-директоров и специалистов по безопасности. Доклады, дискуссии и практические кейсы бесплатно проводят практикующие специалисты крупных компаний Беларуси, России и Украины. Профессиональное комьюнити собрало уже 400 специалистов.  

Присоединяйтесь к сообществу dev.by

Читать

Читайте также
Проверили сами себя. Как hoster.by аттестовывал свою систему защиты информации
Проверили сами себя. Как hoster.by аттестовывал свою систему защиты информации
Проверили сами себя. Как hoster.by аттестовывал свою систему защиты информации
Закон о персональных данных ушел из заголовков, но не из реальности. Собственники бизнеса опасаются проверок и подсчитывают, во сколько им может обойтись аттестация у стороннего подрядчика. У hoster.by особая история — так получилось, что сначала компания аттестовала сама себя, а потом начала предоставлять эту услугу рынку. Почему процесс аттестации растянулся на полгода вместо «пары месяцев», какие сложности возникали на разных этапах проекта и где можно подстелить себе соломку, рассказывает эксперт по информационной безопасности Дмитрий Таран. Процесс аттестации — это вершина «айсберга». И перед получением аттестата необходимо пройти весь путь — проектирование, создание и аттестацию систем защиты информации.  Задолго до вступления в силу Закона о персональных данных существовали другие нормативные акты в области защиты информации. У hoster.by внушительная база в 150 000 клиентов, которые покупают домены, хостинг, облака и администрирование. Компания хранит и обрабатывает терабайты данных, включая персональные. Для их безопасности и соблюдения требований законодательства провайдер инициировал аттестацию систем защиты информации, вспомнить о которой сейчас как никогда актуально. 
hoster.by продолжит продажу SSL-сертификатов для сайтов всех доменных зон
hoster.by продолжит продажу SSL-сертификатов для сайтов всех доменных зон
hoster.by продолжит продажу SSL-сертификатов для сайтов всех доменных зон
Техника работает, но обновлений не будет. Как уход Cisco повлияет на провайдеров
Техника работает, но обновлений не будет. Как уход Cisco повлияет на провайдеров
Техника работает, но обновлений не будет. Как уход Cisco повлияет на провайдеров
Американская DigiСert остановила выпуск SSL-сертификатов для России и Беларуси
Американская DigiСert остановила выпуск SSL-сертификатов для России и Беларуси
Американская DigiСert остановила выпуск SSL-сертификатов для России и Беларуси

Хотите сообщить важную новость? Пишите в Telegram-бот

Главные события и полезные ссылки в нашем Telegram-канале

Обсуждение
Комментируйте без ограничений

Релоцировались? Теперь вы можете комментировать без верификации аккаунта.

Комментариев пока нет.