Милі та пухнасті

Блог

  • [Кейс DevOps] Решения для E-commerce. Часть 1

    Архитектура решения

    На уровне приложений:  основное fpm,nginx, и solr для индексов и фильтров.

    Также выделены окружения для разработки и тестирования.

    Взаимодействие между ними и продуктивной средой:

    Для тестирования есть QA Enviroment и есть Pre-Release Enviroment. Мы используем Jenkins. Там настроены deploy jobs так, что можно сделать деплой на QA с любой ветки.  Если, например, выбрана ветка с именем 10, то развернутое приложение будет доступно по  домену 10. То есть если разные QA инженеры  тестируют разные ветки, то для каждого из них приложение будет доступно по разным доменам.  Фактически это отдельно стоящие сервера, на которых, при деплое, разворачивается минимально необходимое для работы приложения окружение.

    Pre-Release Environment –  он полностью повторяет Production Environment. Разница между ним и QA в том, что если на QA используется одна база, и solr в одном экземпляре, то на Pre-Release будет так, как на Production: если на Production – solr-cloud и MariaDB в кластере, то они же будет и на Pre-Release. Это необходимо для того, чтобы с минимальными отличиями повторить Production Environment. Прикол в том, что на QA (из-за экономии средств) зачастую делается все на одном сервере, в то время как в Production Environment существует избыточность для обеспечения отказоустойчивости. Таким образом, в Production Environment обновление приложения может занять больше времени. А на QA будет сложно заметить, что база может оказаться заблокированной на 5-7 минут. Также, используя только QA, сложно оценить, насколько долго вообще будет проходить обновление в Production Environment. Для выявления таких вот особенностей поведения приложения в Production и нужен Pre-Release Environment.

    Что касается взаимодействия – суть в том, чтобы прописать jobs на Jenkins так, чтобы больше никуда не лазить. Нужно разливать QA – раздал права на развертывание QA инженерам и все. Непосредственно развертывание выполняется автоматически без участия администратора. Возможность развертывания Production версии в нашей компании доверена только TeamLead’ам. Также нужно автоматизировать задачи восстановления среды после тестирования. Вообще автоматизировать нужно все, что можно автоматизировать. Такова идеология. И она себя оправдывает.

    Есть еще окружение разработчика. Оно индивидуально для каждого программиста.

    Процесс работы с Development, QA, Production

    Development  среда  настраивается с помощью Vargant и Ansible.  То есть приходит новый разработчик. Ему выдают отдельную машину, на которой он устанавливает желаемую ОС и VirtualBox+ Vargant. Далее он запускает background task, и в течение 1,5 часов ему накатывается вся необходимая среда.  Таким образом, нет Development окружения на сервере. У каждого девелопера оно локально на своем тазике. Такой подход используется потому что есть разные ОС под которыми работают: и винда, и маки, и друие. Если разворачивать Development Environment с помощью докера, могут быть проблемы у тех, кто использует Windows, например. Именно по этому был изначально выбран VirtualBox и Vargant. То есть Vargant запускает уже готовые боксы, со внутренностями которых уже работает Ansible. Плюс такого решения в его кроссплатформенности.

    Реализация QA

    QA реализован на отдельных серверах.  А Development Environment  – это не отдельный сервер с виртуальной машиной на VirtualBox под каждого разработчика. Когда то была такая практика, но она себя не оправдывает. Слишком много возни с сервером, и раздачей прав. Пришли к тому, что у каждого разработчика  стоит «тазик» с 16 ГБ и Core  i7. Для настройки рабочей машины, он делает gitClone с репозитария, где лежит файл скрипта и плейбуки Ansible. Разработчик локально ставит себе виртуальную машину с полным окружением для проекта. То есть у каждого программиста локально стоит все окружение.  Это распределенная система.

    Для того, чтобы автоматизировать развертывание рабочего места можно в Jenkins создать job для сборки образа и дать разработчику несколько  вариантов настройки своего окружения: либо самому запустить скрипты и подождать час-полтора пока это все накатится, либо скачать с сервера готовый образ виртуальной машины. Второй вариант  может быть плюсом, когда криворукий программист что-то напортачил, и нет времени и\или желания с этим разбираться.  Даешь образ и все готово.

    Проблема различных версий php, модулей, и прочего ПО

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

    Одного образа на всех у нас нет. Есть проект, и есть требования под проект. Это можно сделать, но только если есть необходимость.

    Например, мы сейчас переезжаем на Symphony 3 и нужен php 7.1. Я на Ansible делаю инсталляцию 7.1. и, да, на Development Environment я имею несколько версий php.  Например, на rpm порту 9000 – php 5.6, на 9001 – 7.1,  и в nginx разруливаю уже хостами. Для переключения консольной версии используем скрипт. Нужно переехать – запусти скрипт. Нужно обратно – еще раз запусти.  Жалоб на такое решение пока не было.

    Используются ли какие-то инструменты по управлению кроме Vargant?  Речь сейчас не только о Development Environment.

    Тут важен подход: где все это будет в облаке или на обычном хосте. Например, работая в облаке, мы больше использовали копирования образов, хотя в запасе всегда был Ansible, который умел все это разворачивать. Сейчас в наземной инфраструктуре Ansible основной инструмент.

    Это был Development Environment. QA – это сервера, на которых уже настроена некоторая среда.

    Процедуры, которые  выполняются при переходе с Development на QA

    Когда разработчик готов, он делает push-request, ТимЛид проверяет и подтверждает push-request, push-request попадает в репозитарий кода, в Jira программист передает задачу на QA-инженера. Тестировщик  видит, что разработчик закончил работу над задачей под такой-то веткой. Тогда он самостоятельно заходит в Jenkins и запускает job для деплоя с такой-то ветки. Допустим у нас  ветка mmm. В процессе запуска QA-инженер делает «bulk with parameters», Jenkins делает запрос в Bitbucket, предоставляя возможность выбора нужной ветки, QA-инженер выбирает mmm и  клацает «ОК». Для него собирается проект на QA серверах из ветки mmm. Собранный проект доступен по адресу mmm.<внутренний домен>

    Собирается все с помощью Composer install – php-шный composer.

    Тест кода на данном этапе

    В этом нет необходимости, но если это нужно, то делается это так. В Jenkins есть возможность запустить новый job автоматически, если предыдущий  завершился успешно. То есть мы говорим об автоматизированных QA проверках, которые запускаются, после того, как задача по развертыванию проекта успешно завершена и проект доступен по запланированному домену.  Сами php-юниты запускаются при инсталляции. Если они не прошли, то деплой проекта завершится неуспешно. Уведомление об этом получает  вся группа. Далее изучаются логи и определяются причины сбоя.

    Вопрос о правах

    У Jenkins есть матрица безопасности (Matrix Security). Когда она включена, имеется  возможность для каждого сотрудника (разработчика, QA-инженера) заводить пользователя, и потом на каждый конкретный Job раздавать права конкретному пользователю. Раздача прав выполняется согласно потребностям и ролям, которые человек выполняет в команде. Каждая компания в этом практически уникальна.

    Стресс тесты на QA

    Стресс тесты имеет смысл выполнять на Pre-release environment, поскольку эта среда  максимально похожа на продуктивную. Поиском потерянных линков, также должны заниматься QA-инженеры, которые тестируют пред-релиз. В качестве альтернативы – есть  автоматизированные тесты на Selenium, которые бегают по сайту и клацают на все, что можно. Эти автоматизированные тесты выполняются после успешно выполненной предрелизной сборки. И Если тест не пройдет, то вся сборка будет неудачной, о чем все узнают.

    Обновление Production environment: автоматически или нет?

    И да и нет. Есть Jenkins Job, который это делает. Но он не делает это автоматически.  У нас есть отдельные QA-инженеры, которые тестируют работу приложения в Pre-release environment. Когда они готовы, они меняют статус задачи в Жира. ТимЛид видит что QA-инженеры закончили  тестирование такой-то фитчи, в такой-то ветке и можно обновлять «боевое» приложение. Он нажимает в Jenkins кнопку «Deploy» и система запускает процесс изменения продуктивной среды.

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

    Об архитектуре приложения

    У нас Galera Cluster. Не тормозит, есть некоторые задержки, но они измеряются в миллисекундах и долях миллисекунд. Но в нашем случае базы не находятся в разных дата-центрах. Они все подключены в один гигабитный свитч.

    Базы в разных дата-центрах будут,  но позже. Будет тоже Galera Cluster. Там нужно настраивать группы, чтобы они между собой реплицировались. Если у тебя есть кластер Galera в одном  дата-центре и кластер Galera в другом (для отказоустойчивости), то за счет правильной настройки групп Galera  сама знает задержки и тормозов из-за этого не должно быть. Мы уже проверили это на тестовом стенде.  Но нужно понимать, что имея подобную схему не нужно писать и на тот и на тот кластер. То есть один дата-центр принимает,  и на второй реплицирует, в случае падения принимать начинает второй. В таком случае падение одного сервера баз данных будет незаметным для конечного пользователя. А одновременно принимать данные в два дата-центра я бы не советовал.

    Фронтов у нас 16 из-за большого объема трафика.

    16 хостов, 3 балансировщика (HA-proxy) с проверкой позади фронтов. Также cloudflare используем:  она cdn-ом выступает.

    Galera для разгрузки  mySQL

    Galera проектировалась изначально. Если бы не было Galera Cluster, был бы какой-то master\slave или master\ master, но с возможностью записи в один. Мне не нравится использование master\slave архитектуры в условиях динамически меняющейся инфраструктуры.  В условиях Galera Cluster это все проще. Она позволяет решить и задачи отказоустойчивости и балансировки одновременно.

    Но все равно при этом стоит HA-proxy перед базами и у него на порт 3308 приходят данные на запись, 3307 – запросы на чтение. 3308 – master, 3307 – slave. Это то, что знает приложение. Но HA-proxy балансирует нагрузку: запись все-равно на один сервер, а чтение на все остальные. Если сервер для записи не отвечает, то HA-proxy переключит на другой сервер записи. Нет такой проблемы, когда нужно что-то делать при падении мастера или писать скрипты, которые отработают в этой ситуации. При тестировании пробовали писать на две ноды – проблемы не обнаружили.

    Для индексов и фильтров используем solr. На большом проекте фильтры  через mySQL сильно нагружают его.

    Как в Solr решаются задачи поддержания актуального состояния индекса при частых изменениях данных

    Это называется кэш. Solr же все вытягивает из MySQL, кеширует грубо говоря. Поэтому этот вопрос – не проблема.

    Мы же говорим о большом проекте. В нем – отдельно фронты, отдельно бэк, и еще отдельно бек с кронами с тасками, грубо говоря Working сервер, который выполняет периодические задачи.

    У Solr есть такая штука – дельта индекс. Работает это следующим образом. Есть полное индексирование, и есть дельта индексирование. При полном индексировании Solr где-то у себя сгружает то, что он накэшил и пока не закончится индексация, он не заменяет имеющуюся информацию.

    При выполнении дельта индексирования из MySQL вытягиваются только изменения. У нас 2 000 000 товаров . Дельта индекс выполняется каждые 3 минуты и длится секунд 40. Полное индексирование проходит за 2-3 часа. Логика такая: Solr постоянно делает дельту,  а во время минимальной нагрузки (в нашем случае – ночью) он делает полное индексирование. Это настраивается php-скриптами, которые запускаются по расписанию.  При этом Solr умный, и если выполняется запущено полное индексирование, он не запустит дельта-индексирование. При попытке запуска будет получено сообщение типа «Извини, но я еще в процессе выполнения создания полного индекса».

    А можно же поставить 2 сервера: на одном  в этот момент выполняется полное индексирование, в то время как второй обслуживает запросы?

    Тут нет проблемы в том, что он не принимает запросы. Он нормально работает. В процессе полного индексирования, Solr успешно принимает запросы и отдает данные. В этом нет проблем.

    Solr Cloud

    При использовании Solr Cloud есть ведущий сервер, и есть подчиненный. Когда на лидере у тебя проходит полное индексирование, он (как и в случае одного сервера) может принимать и отдавать данные. Нет каких-либо блокировок.  Когда на первом узле создается полный  индекс, задача второй – ждать изменений.  Лидер не применяет изменений пока не закончится индексирование ядра. Когда это завершено, ведущий сервер начинает «выливать» на подчиненные все изменения.  По-моему, он просто копию файла делает.

    Кэш при добавлении или изменении индекса

    Товары добавляются дельта индексом и при этом кэш не сбрасывается. Но есть нюанс. Добавление или изменение товаров, то есть обновление кэша вследствие изменения данных, в базе он делает с помощью дельта индексирования, но если в таблицу  добавлено новое поле, то нужно делать полное индексирование. То есть Solr не сможет дельтой стянуть новое поле, потому что он об этом поле ничего не знает. Исходя из этого, при добавлении полей или изменении настроек необходимо пересоздавать полный индекс. Ответ на вопрос – Solr не скидывает кэш самостоятельно, только если указать опцию «clear All» при запуске полной индексации.

    Как все это резервировать?

    Основное это база. Ночью делаем дамп и каждые 30 минут – инкрементальный на EXABackup.

    Для  Solr есть url-request. А фронты – зачем их резервировать, если их 16? Есть бекап на Bacula, который сохраняет некоторые конфиги, но им ни разу не пользовались. И нет уверенности, что будут. Поскольку их 16 и есть Ansible, который их раскатывает. Если упало сразу много хостов, то как только подняты новые сервера, накатывается окружение с помощью Ansible и поверх деплоится приложение.

    Что мониторится и как отслеживается

    Внутри – Zabbix – он мониторит. Для сбора статистики, анализа и понимания, что происходит – Grafana.  Собирает множество метрик. Если что-то лагает – там можно найти объяснения. И внешней – Monitis. Я за то, чтобы не использовать лишнее ПО, поэтому иногда я пользуюсь хитростями. Например, для того, чтобы без агента мониторить базу через Monitis, я поднимаю apache на 81 порту, за которым слежу с помощью Monitis. Далее я пишу скрипт, который проверяет состояние базы, и  если она упала – опускает apache. Что в свою очередь отслеживает Monitis. Возможно, это не пример для подражания, но почту от Zabbix я не читаю, смотрю консоль пару раз в день, а sms от Monitis мне и ночью прийдет. Таким образом, отслеживаю критические моменты, которые происходя прозрачно для пользователя приложения.

    Качество кода 

    Плохой код не должен проходить на  уровне QA. Если же это не отследили, и проблема попала в продуктивную среду, необходимо  просто откатиться на одну сборку назад с помощью Jenkins. То есть при деплое  должно быть 5 сборок в Production Environment, чтобы можно было сделать откат на любую из них. Это все решается линками . Если такое  случилось – откатываем назад, ищем в Grafana и смотрим, где были нагрузки и почему . В Grafana метрики должны быть по максимуму по всем серверам, сервисам и приложениям.

    И что самое главное, практически весь стек бесплатный.

     

  • Обновление MySQL на Percona Server

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

    Многие пользователи интересуются, как заменить старую версию новой. Это неудивительно, поскольку сервер может похвастаться весомыми преимуществами: совместимая вилка движка InnoDB, что обеспечивает качественную обратную связь с оборудованием, стабильная работа при любой нагрузке, наличие дополнительных метрик, новая схема аутентификации с возможностью работы с базами данных.

    План обновления MySQL

    Прежде чем заняться обновлением, необходимо проверить сервер. Он обязательно должно соответствовать нескольким требованиям:

    • рабочие облака Debian, Ubuntu или CentOS;
    • загрузка новой Droplet или MySQL / MariaDB;
    • минимум один гигабайт оперативной памяти;
    • обеспечение копирования информации на облако (необходимо для замены некоторых файлов) и конфигурации.

    Теперь стоит рассмотреть, каким образом осуществляется обновление MySQL на Percona Server.

    1. Для начала следует проверить совместимость версий. Percona Server загружается и устанавливается при условии, что на устройстве стояли нужные версии MySQL (то есть, 5.6, например, меняется на 5.6). Если пользователь не обратит внимания на этот момент, то необходимые компоненты не запустятся. Запуск системы в целом не состоится. Так что в первую очередь требуется проверить, та ли версия загружена на устройство. Это можно сделать при использовании специального пароля. После надо найти уже установленную версию. 
    2. Затем нужно удалить старый компонент MySQL. Причем необходимо убрать все элементы, загруженные ранее. Однако на всякий случай их надо скопировать. Перед процедурой обновления MySQL на Percona Server специалисты советуют остановить работу сервера базы данных командой service mysql stop.
    3. Теперь можно переходить непосредственно к установке Percona. Далее пользователю надо загрузить и добавить Percona APT или yum-репозитории. Также следует выяснить, какой дистрибутив применяется на сервере. После чего, нужно добавить в командную строку комбинацию nano /etc/apt/sources.list.
    4. Как только пользователь сохранит главный, необходимый файл, ему надо прикрепить пакет Percona. Алгоритм действий простой: создается новый файл, который затем открывается в текстовом редакторе (Vim или Nano, например). После этого можно обновить программу.
    5. Затем система предложит принять пакеты и ключи к ним. На оба предложения надо ответить согласием. Таким образом, в установке не произойдет никаких ошибок, все пройдет нормально. Если во время установки они все же возникли, то следует еще раз проверить, действительно ли были удалены все компоненты старой версии программы. 
    6. Остается лишь создать конфигурацию, перед которой надо скопировать файлы, чтобы не возникало проблем с файлом PID (иногда он может находиться внутри другой папки, что создает трудности в работе сервера). Это мера предосторожности для следующих процедур конфигурации.

    После загрузки и установки пользователь должен проверить состояние сервера (все хорошо запускается, ничего при этом не вылетает). Наиболее распространенный метод – попытка подключения к базе данных с помощью клиента и вход с паролем.

    Чтобы не допустить распространенных ошибок и провести обновление MySQL на Percona Server грамотно – выбирайте услугу администрирования БД на сайте и обращайтесь к нашим специалистам. Будем рады помочь!

  • Уязвимости облачной инфраструктуры

    Кибератаки способны навредить кому угодно. Жертвами становятся простые люди и серьезные политические организации. Для бизнеса важно держать информацию в облаке, которое защищено от несанкционированного входа. IT-безопасность – это серьезный элемент, который учитывается при написании каждой строчки кода. Выделяется некоторая степень политики безопасности и тестов. Они помогают предотвратить распространенные ошибки, которые появляются при внедрении облака.

    Можно выделить следующее:

    • похищение и взлом аккаунтов в социальных сетях и Интернете;
    • внутренние угрозы;
    • минимальное количество процедур по идентификации;
    • разделение контроля доступа и прав;
    • неправильная настройка;
    • нарушение конфиденциальности вносимых данных.

    Если речь идет о нарушении конфиденциальности данных, то о них печется любая особа. Информация, которая не должна быть обнародована, получает широкую огласку. Причиной утери конфиденциальности может быть: человеческая ошибка, целевая атака, отсутствие мер безопасности и обычная уязвимость приложений. 

    В таком облаке есть своя специфика:

    1. Если разделить общие ресурсы, можно получить большую поверхность атаки;
    2. Поставщики облачных услуг являются «лакомым кусочком» для хакеров. Это связано с тем, что они хранят большой объем полезной информации.
    3. Распределение ответственности идет в пользу. За безопасность данных отвечает клиент, а за доступность инфраструктуры и некоторых инструментов – провайдер.

    Чтобы избежать неприятностей, нужно создать защиту в клиентском облаке, меньше привилегий, ввести мониторинг в облаке. Все это стоит объединить общим надежным планом реагирования на любые инциденты. 

    Угрозы для облака

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

    Безопасность в облаке: уязвимости при неправильной настройке:

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

    Другая распространенная кибератака в облаке связана с уязвимостями вокруг контроля доступа. Часто это происходит из-за слабых методов аутентификации, авторизации или связано с уязвимостями, которые обходят эти методы.

    Облачная безопасность: общие уязвимости арендатора – это сложный вопрос, требующий серьезного вмешательства. Есть действенный способ обойти опасность.

    1. Обеспечить шифрование данных с помощью надежных методов и правильных настроек, управляемых и контролируемых систем управления ключами.
    2. Для особо уязвимых рабочих нагрузок использовать выделенные, единичные или «голые» экземпляры, снижая риск размещения злоумышленником вредоносной информации.
    3. Для уязвимых рабочих нагрузок использовать виртуализацию для изоляции.
    4. Выбирать облачные предложения, в которых критические компоненты были оценены в соответствии с национальным информационным обеспечением.

    Облачная безопасность: уязвимости цепочки поставок. По некоторым данным, этот класс атак на цепочку поставок является редким, сложным и в основном относится к сфере ответственности поставщиков услуг.

    Чтобы Ваше облако было в безопасности – обращайтесь к профессионалам. ITFB всегда к Вашим услугам!

  • Kubernetes – что это

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

    Система Kubernetes – что это, и как работает? Так называется программное обеспечение от Google, созданное для управления контейнерами с целью упрощения декларативных настроек и автоматизации. Контейнерами являются приложения, имеющие свою файловую систему, память, процессор и многое другое. С помощью системы Engine контейнеры собираются в кластеры. Все это архивировано и представлено таким образом, что приложение может работать вне операционной системы. Но без платформы Kubernetes управлять ими на большом количестве серверов было затруднительно. В пределах своей экосистемы Kubernetes имеет перечень специфических определений.

    1. Узел. Отдельная площадка, где развернуты контейнеры. Каждый cluster узла содержит сервисы, запускающие приложения и компоненты для централизованного контроля узла. 
    2. Pod. Базовая единица, обеспечивающая запуск приложений и их управление. Для развернутых на поде контейнерах существует уникальный IP-адрес, для исключения рисков конфликта приложений с использованием фиксированных номеров портов. 
    3. Том. Общий ресурс, предназначенный для хранения развернутых на одном поде приложений. Это позвоялет совместное использование контейнеров системой.
    4. Kubelet. Связующее звено, агент, который взаимодействует с главным узлом и отвечает за мониторинг приложений внутри узла. 

    Что же представляет собой Kubernetes в действии? Образ контейнера состоит из нескольких слоев, в которых находятся элементы приложения. Один и тот же слой может использоваться для разных контейнеров, например, в качестве базового для приложений конкретной компании. Так упрощается deployment и хранение имеющихся образов, поскольку отпадает необходимость хранить на сервере большое количество копий. Еще больше упрощает работу менеджер пакетов helm, устанавливаемый с платформой Kubernetes.

    Для управления контейнерами создано много инструментов, самый известный из которых – Docker. Но его минусом является то, что работает он только на одном хосте. Kubernetes решает эту проблему и легко позволяет начать управление группами приложений сразу на множестве серверов. Использование системы дает возможность построения Development Operations и DevOps, чем увеличивает ее популярность. 

    Настройка Kubernetes

    Для ознакомления с возможностями Kubernetes настройка осуществляется посредством облачных платформ, например, Google Cloud Platform или Azure. Для начала необходимо создать под и присвоить ему имя, а данные внести в файл описания ресурса. Для внешнего доступа к приложению нужен еще один ресурс Kubernetes, и сделать его проще всего путем перенаправления портов. Далее с помощью программных настроек необходимо выполнить ряд действий.

    1. Для реализации масштабирования создается новый pod. Его описание должно быть аналогично первому, за исключением имени. Проверяется запуск обоих подов.
    2. Созданные поды получают одинаковые метки, которые прописываются в настройках сервиса. Файлы с описанием необходимо сохранить и выполнить команды по конфигурации подов.
    3. Выполняется описание сервиса балансировки нагрузки. Самый удобный способ балансировки трафика – с помощью Ingress. В описании следует указать тип ресурса, порт приема запросов, вид протокола, перенаправляющий порт и данные об объекте.
    4. Перед запуском проверяется состояние сервиса.

    Имена созданных ресурсов не должны повторяться в пределах одного namespace. Система Kubernetes наиболее эффективна при запуске конструкций с микросервисами. В полной мере преимущества программы раскрываются при наличии платформы виртуализации.  

    Хотите попробовать? Обращайтесь за проектированием и внедрением Kubernetes в ITFB!

  • Анализ производительности сервера

    Анализ производительности сервера

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

    Процессор

    Для начала воспользуемся командой top:top определение нагрузки сервера

    Смотрим на значения load average, us, id, wa и столбец %CPU:
    • load avegare представлен тремя цифрами, которые обозначают среднее значение загрузки сервера за 1, 5 и 15 минут. Чем меньше значение, тем лучше работает сервер. Данная характеристика помогает оценить нагрузку сервера в минимальные сроки.  Значения не должны превышать общего числа процессоров в системе.
    • us – загрузка пользовательскими процессами.
    • id – процент времени простоя процессора, значение должно быть большим, в норме – от 80. но сильно зависит от конкретной задачи запущенной на сервере.
    • wa – ожидание операций ввода/вывода, чем ниже, тем лучше (в противном случае процессор слишком долго ожидает ответы от диска или сети).
    • в столбце %CPU можно увидеть процессы и сколько процессорных ресурсов они потребляют.
    Похожая утилита, но с дополнительными возможностями (поиск и фильтрация, вывод дерева процессов, групповые операции над процессами завершение процессов и т.д.), большей наглядностью и возможностью настройки — htop.анализ производительности системы

    Также удобно использовать atop, позволяет мониторить не только процессор а также память, диск, сетевую активность(с модулем), а также хранить историю.

    Для общей оценки нагрузки на процессор можно использовать команду vmstat обычно установлена по умолчанию. При использовании без параметров выведет среднее значение с момента последней загрузки. В данном примере используется ключ -w для широкого представления а также параметр 5 который выводит результат сбора за последние 5 секунд. В колонке CPU видно что среднее время ожидания процессора 91% что является высоким показателем но за последние 5с всего 68% , но эта статистика по всем ядрам и процессорам.

    Память

    Использование памяти можно посмотреть с помощью команды free (установлена по умолчанию). Для более читабельного формата, примените ключ -h:
    В результате работы команды интересуют 2 значения: free и swap (used). Free показывает, сколько сейчас свободно оперативной памяти. Маленький размер свободной памяти не говорит о каких-то проблемах, но за ним нужно следить, чтобы убедиться, что памяти будет хватать даже при пиковых нагрузках. Важно обратить внимание на использование файла подкачки (swap). Если если значение swap больше нуля, значит часть данных не помещается в оперативную память и вытесняется на диск, а так как дисковые операции чтения и записи гораздо медленнее аналогичных для памяти, то падает производительность всей системы. Но в данном примере не стоит переживать из-за свапа так как в предыдущем примере мы видели на сриншоте команды vsstat поле swap c 2 параметрами
    si (swap in) — количество блоков в секунду, которое система считывает из раздела или файла swap в память;
    so (swap out) — и наоборот, количество блоков в секунду, которое система перемещает из памяти в swap.
    В идеале, значение обоих должно быть около нуля или, по крайней мере, не более 10 блоков/секунду.

    Ту же информацию с некоторыми подробностями можно получить и другим путём:

    Дисковая подсистема

    Сначала стоит проверить наличие свободного места. Проверяем командой df. Как и в случае с free, используйте ключ -h для более читабельного вида:

    Старайтесь всегда иметь достаточно свободного места (Avail) на используемых разделах. И не забывайте про инноды ведь они могут закончится раньше чем свободное место. Посмотреть командой df -i

    Дисковая подсистема может создавать задержки, если объём одновременно читаемой или записываемой информации превосходит пропускную способность диска. Это можно определить с помощью утилиты iotop.

    Важные для нас показатели: Actual DISK READ и Actual DISK WRITE. Если значения высоки (десятки и сотни M/s), то обратите внимание в таблице на процессы, которые производят наибольшую нагрузку и проанализируйте, почему это происходит и как нагрузку можно снизить (кеширование, отключение лишних логов, настройка базы данных и т.д.).

    Сеть

    Чтобы посмотреть объёмы сетевого трафика в реальном времени, можно использовать простейшую утилиту cbm, или atop

    Но если вы хотите узнать IP-адреса устройств, обменивающихся трафиком с вашим сервером. Это можно сделать с помощью утилиты iftop.

    С сетью возможна только одна проблема – среднее значение Total близко к пропускной способности сетевого интерфейса сервера. Если это так, то вероятно, пора либо бороться с DDoS-атакой, если это она, либо планировать масштабирование.

    Вывод:

    Итак подведем итог, что проверять на сервере

    1. Проверяем общую нагрузку на систему с момента загрузки утилитой vmstat.
    2. Смотрим параметры загрузки системы с помощью atop. Если необходимо дополнительно посмотреть нагрузку на диск или на сеть то устанавливаем iotop и iftop coответственно.
    3. Смотрим нагрузку на дисковую подсистему и сеть
    4. Проверяем параметры настройки основных сервисов установленных на сервере. (например apache, mysql, java)
    5. Если есть возможность настроить atop на логирование состояний и провести тестирование нагрузкой.

    Если не получается найти проблему самостоятельно, обращайтесь к нам, наши специалисты обязательно найдут и устранят проблему с производительность.

  • Как пандемия меняет стратегию для Облака и DevOps

    Как пандемия меняет стратегию для Облака и DevOps

    Роль Облака все растет, а в новых реалиях пандемии и закрытия целых стран на карантин становится критически важной для многих бизнесов. Поэтому сегодня компании готовы (а иногда и вынуждены) пройти extra mile, чтобы быстро воплотить те изменения, на которые долго не решались. Ведь это дает возможность не только выстоять в турбулентные времена, но и получить дополнительные конкурентные преимущества.

    Я поделюсь своим видением того, почему это происходит, какие именно потребности появляются у компаний и какие новые возможности кризис открывает сервисным компаниям в сфере Клауд и DevOps.

    Изменения вызвала пандемия

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

    Сейчас клиентов можно разделить на три условные категории:

    • Неожиданно стремительно растут – количество клиентов увеличилось в сотни раз за считанные дни. ИТ-инфраструктуры компаний к этому не были готовы, соответственно не могут выдержать такой нагрузки. Сюда прежде всего относятся ритейлеры с сильной онлайн-составляющей, онлайн-сервисы и e-learning платформы.
    • Неожиданно стремительно падают – спрос снизился почти до нуля, доходы падают. Самое важное для этих компаний – сократить операционные расходы к минимуму, сэкономить каждый доллар, чтобы уберечь бизнес и потерять как можно меньше людей. Уменьшение затрат на поддержку ИТ-инфраструктуры играет важную роль. Именно в этом компании нуждаются в нашей помощи. В категорию попадают, в частности, туристическая отрасль и офлайн-ритейл.
    • Пока стабильные – настоящая ситуация мало повлияла на основной бизнес этих компаний. Но они не знают, что их ждет дальше.

    Неопределенность будущего – общая черта для всех категорий. Сейчас никто не знает, как ситуация будет разворачиваться. Это приводит к следующим последствиям:

    1. Даже те компании, которые сейчас в выигрыше, не готовы к значительным трансформациям и инвестиций в ИТ-инфраструктуру. Такие дорогие и сложные услуги, как изменение архитектуры или модернизация программ, в ближайшем будущем будут актуальны только для небольшого количества компаний, требующих диджитал-трансформации. Основная часть старается не рисковать и вкладывать только в том, что принесет мгновенную пользу.
    2. Фокус смещается из долгосрочных стратегий, которые приносят большую выгоду в долгосрочной перспективе (от 1-2 лет), на краткосрочные, результат которых слабее, однако ощутимым уже через несколько месяцев или даже недель.
    3. Приоритетом становится масштабируемость (scalability) и эффективность как инфраструктуры, так и бизнеса в целом. Ведь нынешний, сильно увеличен / уменьшен спрос потенциально вернется к прежнему уровню, как только ситуация стабилизируется. Но может случиться и очередной резкий скачок. Компании понимают, что их инфраструктура должна быстро адаптироваться, чтобы бизнес мог функционировать в различных условиях. Это должно происходить оперативно и без значительных инвестиций (например, без построения датацентра, закупки серверов).

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

    Поэтому выделю несколько ключевых мнений относительно того, куда движется рынок DevOps и Клауд-сервисов.

    Оптимизация стоимости инфраструктуры

    По данным State of the Cloud Report , в 2020 году 82% энтерпрайз-компаний считают оптимизацию расходов на инфраструктуру в Облаке основным приоритетом. А для более трети из них это большой вызов. С традиционными датацентрами ситуация еще хуже – большинство компаний утверждает, что не является оптимизированными и это приводит к перерасходу около 30% ресурсов.

    Мы регулярно получаем от клиентов запросы на эти услуги. Но сейчас оптимизация становится еще более актуальной. Для части компаний это вопрос выживания. И даже те, у кого ситуация более или менее стабильная, понимают, что пришло время пересмотреть свои практики.

    Коротко о том, как выглядит оптимизация

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

    Что получает клиент? Как показывает практика, реализация краткосрочного плана может сократить бюджет на  15-30%, долгосрочного – на  20-50%. Даже для бизнеса, которые пошли на убыль, оптимизация расходов – это не только вопрос сэкономленных средств, но и инвестиция в том, насколько быстро и эффективно они смогут восстановить процессы, когда ситуация нормализуется и нужно будет возвращаться к активной работе.

    Один из наших последних кейсов – клиент тратил более 300 тыс. Долларов в месяц на поддержку Облачной -инфраструктуры в Azure, при том она была достаточно неплохо оптимизирована и использовала большинство best practises. Компания пришла к нам в конце февраля с запросом сократить эту сумму как минимум на 35%, чтобы иметь возможность сохранить команду. По состоянию на конец марта нам удалось уменьшить ее до 243 тыс. Долларов, до конца апреля – до 157 000. Среди основных шагов, которые помогли этого добиться, выделю следующие:

    • Объединили региональные Dev / QA / UAT в один глобальный расшаренный Kubernetes-кластер.
    • Оставили на выделенном пуле серверов только ворклоады, которые плохо переживают перезапуск. Большинство ресурсов в кластере живет на спот-инстансах.
    • С помощью автоматизации перевели большинство QA / UAT на on-demand модель, где среда стартует только тогда, когда оно необходимо, и автоматически останавливается через некоторое время.
    • Внесли много изменений в профиля ресурсов для уменьшения их performance. Это повлияло на такие метрики, как Build Time / Test Time. Но поскольку во время кризиса процесс разработки перешел в режим «только приоритетные продукты», общее количество Комит, билдов уменьшилось, загруженность всей системы тоже снизилась, соответственно Time To Production (Market) почти не изменился.

    Вы можете спросить, почему к этой оптимизации пришли только сейчас? Ведь все можно было сделать и в спокойные времена. И вы правы, эту инфраструктуру и процессы стоило оптимизировать уже давно. Часть из этих улучшений была даже заложена в нынешнем плане. К сожалению, только кризис помог бизнеса понять важность эффективности их ИТ-инфраструктуры и процессов. Только угроза потерять этот бизнес подтолкнула наконец приоритезировать время девелоперов на нужные изменения в коде, сфокусировать Автотест и DevOps-команды на разработку нового подхода для тестирования продуктов и инфраструктуры. Уже сейчас менеджмент активно планирует развертывание этого нового подхода на Production, который поможет сэкономить еще примерно 30-40 тыс. Долларов в месяц.

    В результате компания будет иметь вдвое больше cost-efficient инфраструктуру, чем до этого.

    оптимизация затрат в облакеРасширение инфраструктуры благодаря использованию публичного облака

    Ведение основной деятельности в собственных датацентрах имеет значительные недостатки, среди которых высокий TCO (total cost of ownership) при низком ROI (return of investments) и сложность масштабирования мощностей. Поэтому все больше компаний начали переходить на гибридные Облакак. По данным IDG , количество организаций, которые хотя бы одну программу или часть инфраструктуры ведут в публичном Клауде, выросла с 51% в 2011 году до 73% в 2018 году, а сегодня уже превысила 90%. Около 44% организаций уже используют одновременно частные и публичные облака, чтобы предоставлять один из своих сервисов.

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

    Немало компаний столкнулись с проблемой, что инфраструктура и бизнес в целом не могут отвечать на вызовы настолько быстро, как это нужно. Согласно еще больше компаний и еще быстрее будут переходить на гибридные Клауды. Поэтому этот тренд совсем не нов. Тогда что же изменилось?

    Около 2/3 компаний, которые начали переходить на гибридную модель, в Облаке размещали только новые проекты, но не были готовы вкладывать ресурсы в переносе туда основного бизнеса, приносящего больше доходов и на значительно усилилось нагрузки сейчас. В таких случаях гибридное облако выглядит так: весь основной бизнес ведут в датацентре, новые проекты запускают в Клауде, но все равно связываются с датацентр, чтобы использовать те данные, которые в нем хранятся. Соответственно то, что эти компании имеют ресурсы в Клауде, не помогает в ситуации, когда нужно быстро масштабировать основной бизнес.

    о мультиклауд

    Еще одна актуальная проблема – то, что не только компании переживают рост нагрузки на сервер, но и Облачные-провайдеры. Например, нагрузка на Azure за март увеличилось более чем 700%. Это влияет на его пользователей – некоторые из них очень зависят от доступных ресурсов для short-time bursts. Оптимальное решение в такой ситуации – расшириться на другой публичный Клауд.

    Среди крупнейших в Европе пользователей одного из публичных Клауд-провайдеров – онлайн-ритейлер, которому с началом эпидемии нужно было быстро расширить бизнес. Но он столкнулся отсутствием свободных ресурсов в датацентрах своего Клауд-провайдера. Поэтому вернулся к мультиклауд-стратегии, которую мы предлагали ему в прошлом году. Теперь мы строим для этой компании решение, которое в краткосрочной перспективе поможет переводить часть нагрузки на Облако другого провайдера. А в долгосрочной перспективе позволит свободно балансировать сервисы между несколькими провайдерами.

    Что эти изменения означают для DevOps-инженеров

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

    С ключевого: экспертиза в работе с Облаками и контейнерными платформами – must have, без этого трудно найти проект. Не очень отдаленная перспектива – решение для гибридных / мультиклаудов и Workload Mobility: Google Anthos, OpenShift и VMware Taznu.

    Планируете переезд в облако обращайтесь, мы поможем спроектировать и внедрить решение, а если уже используете облако, мы можем оптимизировать затраты.

  • Новые веяния поддержки в условиях изменений

    Если мы говорим о том, что разработка может быть запланирована, мы сделали большой план и  при чем быстро. То в условиях того, как вы продаете системное администрирование – это несколько сложнее.

    Представьте себе работу админа. Сложно представить, что у админа план будет расписан. На этой неделе случится несколько аварий и они произойдут одна за другой. О том, как мы пытаемся с этим жить, я и хочу рассказать.

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

    В течении 15 минут мы должны прийти, и если мы можем, мы должны это починить. Если мы знаем, с кем связаться, не работает хостинг – связаться с хостингом. Если это проблема с выкладкой кода, связаться с разработчиками, клиентами и вместе попытаться ее решить. С

    Сейчас у нас на поддержке много сайтов. Есть небольшие интернет-магазины, есть большие интернет-магазины, есть крупные проекты.  В чем главная проблема? На любую аварию, допустим, реагируют в течении 15 минут, 24/7, 7 дней в неделю.

    По сути, что такое авария? Авария – это может в данный момент закончиться место на диске, может показать, что скоро закончится. Если мы говорим, что среагируем и начнем что-то делать за 15 минут – это означает, что дежурный администратор должен это сделать за 7-8 минут. Он сидит, ему прилетают оповещения. Он видит графики. Он может принять  или не принять заявку. В случае необходимости начать чинить.

    Сейчас у нас таких оповещений от 100 до 500 за час на одного человека. Днем – очень много. Ночью их бывает меньше. Интернет-магазины, к примеру, любят начать черную пятницу раньше на один день. 3 года назад они это сделали в пятницу, 2 года назад – в четверг. В этот год – в среду. И каждый год они говорят, что больше не будут участвовать.

    У нас один клиент заказал рассылку на 300 тысяч человек, через пол часа мы сказали, что вообще никаких рассылок делать не будем. Основная поддержка у нас идет через чаты. Ни система, ни клиент должны сказать, что что-то упало, а мы должны об этом сказать, и мы должны оповестить его об этом.

    Это выглядит примерно так: может быть клиент сказал, что у нас один из менеджеров случайно поменял тип у всех товаров, пожалуйста, восстановите базу данных немедленно. А может быть мы увидели, что резко повысился рост нагрузки и пишем клиенту, говорим, что видим рост нагрузки, делали ли вы что-то на серверах. Если делали, тогда мы будем знать, что это за нагрузка. В таких чатах у нас получается до 50 сообщений каждые 10 минут. Админы дежурные сидят в чатах и разговаривают с людьми. 50 сообщений  за 10 минут.  До 8 задач ставится через чат одновременно.

    В чем смысл? Если попросить клиента написать задачу тикете, клиент будет пытаться сформулировать ее. Сделает это своеобразно и потом большое количество времени уйдет на то, чтобы попытаться формулировать эту задачу правильно.

    Если клиент начинает общение в чате, можно это объяснить немедленно, а потом уже перевести им, объяснить немного проще. Существует небольшая проблема, поскольку задача в чате не выглядит как цельная задача для администратора. Таких задач происходит порядком 5 за час. То есть, это может быть – создать в меню конфигурацию на сервере, поставить софт и т.д.

    Соответственно у нас есть проблемы. Сейчас 90 чатов активных каждый день, при этом посторонних очень много. У нас много задач, если люди делают что-то через чаты, и мы никак за этим не следим, их можно просто потерять. Оповещений очень много, и на них нужно реагировать вовремя.

    По сути, это наша основная услуга. Если мы не среагируем, то мы нарушим обязательство с нашей стороны. А админ может пропустить, как за этим уследить. Начали мы с простого. Если мы делаем поддержку через чат, то главная проблема заключается в том, что чат – это такая штука. По сути, создатели любого мессенджера не предполагали, что кто-то может попытаться им воспользоваться для такой работы.

    Если у вас есть телеграмм или скайп, никакой функциональности нет с тем, чтобы осуществлять контроль в чате. У нас есть внутренняя система. Наш сотрудник должен ответить в чате до 15 минут со времени вопроса клиента. Представьте, что у вас есть мессенджер, где вам красным подсвечивается, что вы до сих пор не ответили. Такого нет. Любые обсуждения в чате могут потеряться. Нужно что-то с этим делать.

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

    Мы посмотрели на него и оказалось, что у телеграма есть одна очень крутая штука. У него есть клиент, который можно бить одновременно на Винду, Линукс. А поскольку у нас была одна довольно большая экспертиза про то, как разрабатывать, мы решили, что в принципе, мы можем попробовать взять свой телеграм и переписать его для себя так, чтобы это решило наши проблемы.

    Какие есть проблемы с мессенджером по сути? Никто не думает, что у человека может быть 80 чатов одновременно. Любой мессенджер показывает достаточно малое количество чатов. Не то, которое нам нужно для регулярной нашей работы. Чаты перепрыгивают постоянно. Если вы сидите в чатах поддержки и тебе пишут часто, то постоянно меняется очередность чатов. Ты можешь нажать не на тот, переключиться не в тот. Непонятно, где мы не успели ответить или где мы уже отвечали и где приближается время, что мы должны ответить. Что мы стали делать?

    Первое, что мы стали делать:

    • уменьшили высоту каждого чата в отдельности.
    • стали отслеживать то, где последний написал клиент, стали подсвечивать чаты, где такое нужно
    • далее начали выбивать чаты по необходимости ответа
    • добавили функцию «отметить все чаты как прочитанные»

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

    Постановка задач

    Клиенты – самое важное. У нас очень много клиентов не айтишных. Это может владелец интернет-магазина, директор и у него ест оффлайновый магазин. Он платит за аренду магазина, сигнализацию, он где-то когда-то нанял студию, она предоставляет ему хостинг и он хочет какую-то защиту.

    Вот как он взял охранное агентство, так он взял и нас для веб сайта. Он может сказать: «Вы знаете, у меня ничего не работает»! Кроме того, если даже мы ставим задачи через чат, некоторые настолько горят, что нет возможности задачу описать, создать тикет, написать администратору. Вот если приходит человек и говорит: «Вы знаете, взломали нашу базу, восстановите ее срочно!»

    Ты же не будешь говорить, что сначала оформишь это в виде задач и дальше мы возьмемся за это и будем держать в курсе. Нет. Ты должен быстро что-то решать. Задачи должны как-то отслеживаться. Собственно, сам процесс переноса задачи с чата- довольно сложная задача. Потому что даже в процессе диалога больше понимаешь, что происходит. Ты в итоге можешь скопипастить что-то в тикет, забыть что это все значит.

    Дальше переходим к сложной части. Мы решили технические проблемы, у нас есть люди. Для того, чтобы посмотреть, как мы с этим справляемся, нужно немного вернуться к прошлому. Сайты нужно поддерживать так, чтобы они не падали.

    Что нужно сделать, чтобы сайт не падал? И в итоге, мы поняли, что для нас услуга поддержки оказалась важнее, чем услуга разработки. Если ты хочешь вырости бизнесово в два раза, тебе нужно больше идей. В начале три человека, потом 6, потом 12, 24. Ты хочешь в два раза больше, а это может быть только тогда, когда ты продашь 40 человек. А если вы представляете услугу охранного агентства, в итоге вы получаете классический админский кейс, вы получаете деньги за то время, пока админ не работает.

    Вам нужно грамотно все настроить первое время, и если потом падать ничего не будет, вы просто получаете плату.

    К 2010 году это стало нашей основной услугой.

    Появились алерты (оповещения).

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

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

    Мы стали делать ретроспективы по любым пропущенным авариям, чтобы понимать, почему мы пропустили и как сделать, чтобы это больше не пропускалось. Начали накапливать базу знаний. Вот дальше оказалось так, что мы начали собирать всю историю алертов за то время, за которое мы работали.

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

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

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

    Есть много людей и как-то нужно сделать, чтобы они взаимодействовали между собой, они обменивались своими знаниями. Знаниями обмениваться очень сложно. Мы поняли, что с людьми нужно разговаривать, потому что люди живут в каком-то своем мире, у них появляются свои тусовки. Оказалось, что 8 часов смена ночью – тоже не очень хорошо. Ты подежурил ночью, ты приехал домой и если у тебя есть какие-то другие дела, ты из не можешь сделать. Соответственно, ты скорее всего опять не будешь спать. Ты поспишь чуть больше, но все равно меньше спишь. И мы поняли, что такие смены должны быть заменены на другое.

    Мы разделили админов на категории. У нас есть дежурные, их смены короткие. Есть админы только на задачах, которые могут отдыхать в процессе работы. Есть админы в офисе, которые выполняют наши задачи. К примеру, сейчас по договору мы не делаем бекапы.

    При этом один из четырех клиентов уверены, что мы их делаем.  Каждый второй приходит без бекапов. Им настроил какой-то фрилансер два года назад. А у нас, если вы не проверяете то, что бекап есть 21 день, скорее всего, их уже нет. У нас сейчас есть двое фултаймеров, которые занимаются тем, что создают бэкапы, рассматривают алерты, проверяют по кругу. У нас появился интерпрайс отдел.

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

    Мало того, что нужно сначала разобраться в том, что нужно делать. Если ты новый человек, можешь сделать что-то не так и испортить все. Поэтому пытаться учить людей – в нашем случае сейчас плохо. Мы хотим сделать так, чтобы можно было брать людей без опыта, учить их потихоньку с этим жить, пользоваться технологиями. Но пока мы не можем. У нас многозадачность. Человека можно научить, либо способность есть у него сразу.

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

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

    Сейчас главное, что у нас получается делать, чтобы люди оставались в компании и хотели продолжать тут работать. Бюрократия неприемлема. Главное – должна быть честность к людям. Проблем еще куча. Есть клиенты которые спрашивают у админов про то, спят ли админы, поскольку их видят и днем, и ночью. У менеджеров нет жизни.

    Когда происходят аварии и клиенты приходят ругаться, Вы не должны переживать, что кто-то на вас ругается.

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

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

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

  • 10 самых распространенных ошибок в использованиии kubernetes

    10 самых распространенных ошибок в использованиии kubernetes

    У нас было много возможностей увидеть немало кластеров в нашем многолетнем опыте работы с kubernetes (как управляемым, так и неуправляемым – в GCP, AWS и Azure), и мы видим, что некоторые ошибки повторяются. В этом нет ничего постыдного, мы сделали большинство из них тоже!

    Я постараюсь показать те, которые мы видим очень часто, и немного расскажу о том, как их исправить.

    Ресурсы – запросы и ограничения

    Это определенно заслуживает наибольшего внимания и первого места в этом списке.

    Запрос ЦП обычно либо не установлен, либо установлен очень низким (так что мы можем разместить много модулей на каждом узле), и узлы, таким образом, перегружены. Во время высокой нагрузки процессорные ресурсы узла полностью используются, и наша рабочая нагрузка получает только «то, что он запросил» и регулирует нагрузку на ЦП , что приводит к увеличению задержки приложения, тайм-аутам и т. д.

    BestEffort (не делайте так):

        resources: {}

    очень низкий процессор (не делайте такого):

        resources:
      requests:
        cpu: "1m"

    С другой стороны, ограничение ЦП может излишне ограничивать блоки, даже если ЦП узла используется не полностью, что опять-таки может привести к увеличению задержки. Существует открытая дискуссия о квоте CPU CFS в ядре Linux и дросселировании ЦП на основе установленных ограничений ЦП и отключении квоты CFS. Ограничения процессора могут вызвать больше проблем, чем решить.

    Перегрузка памяти может доставить вам больше проблем. Достижение лимита ЦП приводит к регулированию, а при достижении лимита памяти ваш модуль перестанет работать. Вы когда-нибудь видели OOMkill ? Да, это тот, о котором мы поговорим. Хотите минимизировать, частоту возникновения? Не перегружайте свою память и используйте Guaranteed QoS (Quality of Service), устанавливающее запрос памяти, равный пределу, как в примере ниже.

    Burstable (более вероятно получить OOMkilled):

        resources:
      requests:
        memory: "128Mi"
        cpu: "500m"
      limits:
        memory: "256Mi"
        cpu: 2

    Гарантия:

        resources:
      requests:
        memory: "128Mi"
        cpu: 2
      limits:
        memory: "128Mi"
        cpu: 2

    Так что может помочь вам при настройке ресурсов?

    Вы можете увидеть текущее использование процессора и памяти модулями (и контейнерами в них), используя metrics-server . Скорее всего, вы уже запускали его. Просто выполните это:

    kubectl top pods
kubectl top pods --containers
kubectl top nodes

    Однако они показывают только текущее использование. Это замечательно, когда есть возможность получить приблизительное представление о цифрах, но вы в конечном итоге захотите увидеть эти показатели использования во времени (чтобы ответить на такие вопросы, какое было использование процессора в пике, вчера утром и т. д.). Для этого вы можете использовать Prometheus , DataDog и многие другие. Они просто получают метрики с сервера метрик и сохраняют их, а затем вы можете запросить и построить график.

    VerticalPodAutoscaler может помочь вам автоматизировать этот ручной процесс – отслеживая использование процессора / памяти во времени и устанавливая новые запросы и ограничения на основе этой основе.

    Эффективно использовать ваши ресурсы- непростая задача. Это как играть в тетрис все время. Если вы обнаружите, что платите много за вычисления при низком среднем использовании (скажем, ~ 10%), возможно, вы захотите использовать продукты на основе AWS Fargate или Virtual Kubelet, которые используют больше серверной модели оплаты / оплаты за использование, которая может быть дешевле для вас.

    Тесты доступности и готовности

    По умолчанию тесты доступности и готовности не указаны. И иногда так и остается …

    Но как еще ваш сервис может быть перезапущен, если возникла неисправимая ошибка? Как балансировщик нагрузки знает, что конкретный модуль может начать обрабатывать трафик? Или обрабатывать больше трафика?

    Люди обычно не знают разницы между этими двумя показателями.

    • Датчик доступности перезапускает ваш модуль, если он выходит из строя
    • Проверка готовности отключается при сбое модуля сбоя от службы kubernetes (вы можете проверить это kubectl get endpoints), и больше не отправляется трафик на него, пока проверка не будет успешно завершена

    И ОБА ЗАПУЩЕНЫ В ТЕЧЕНИИ ВСЕГО ЖИЗНЕННОГО ЦИКЛА. Это важно.

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

    Другой – сказать, что если во время жизни модуля он перегрелся, обрабатывая слишком большой трафик (или дорогостоящие вычисления), чтобы мы не посылали ему больше работы и не давали ему остыть , тогда проверка готовности завершается успешно и мы снова начинаем посылать больше трафика . В этом случае (при отказе датчика готовности) выход из строя также датчика живучести будет очень контрпродуктивным. Зачем вам перезапускать модуль, который здоров и выполняет много работы?

    Иногда отсутствие определения любого датчика лучше, чем определение их неверно. Как уже упоминалось выше, если датчик живучести равен датчику готовности, у вас большие проблемы. Возможно, вы захотите начать с определения только одного датчика готовности, поскольку тесты жизнеспособности опасны.

    Не пропускайте тесты, если какая-либо из ваших общих зависимостей не работает, это приведет к каскадному отказу всех модулей.

    LoadBalancer для каждого http сервиса

    Скорее всего, у вас есть больше http-сервисов в вашем кластере, которые вы хотели бы представить внешнему миру.

    Если вы предоставляете услугу kubernetes как a type: LoadBalancer, ее контроллер (в зависимости от поставщика) будет предоставлять и согласовывать внешний LoadBalancer (не обязательно L7 loadbalancer, более вероятно, L4 lb), и эти ресурсы могут дорого обойтись (внешний статический адрес ipv4, вычисления, посекундные ценообразование…).

    В этом случае совместное использование одного внешнего loadbalancer может иметь больше смысла, если вы предоставляете свои услуги как type: NodePort. Или еще лучше, развертывать что – то вроде Nginx-ингрессии-контроллер (или traefik ) является единственной NodePort конечной точкой подвергающейся воздействию внешнего loadbalancer и маршрутизации трафика в кластере, основываясь на kubernetes Ingress ресурсов.

    Другие внутрикластерные (микро) сервисы, которые общаются друг с другом, могут обмениваться данными через сервисы ClusterIP и обнаружение DNS-сервисов «из коробки». Будьте осторожны, не используйте их общедоступные DNS / IP-адреса, так как это может повлиять на их задержку и стоимость облака.

    автоматическое масштабирование кластера с некубернетским охватом

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

    Представьте, что запланирован новый модуль, но запрашивается весь доступный процессор, и модуль застрял в состоянии ожидания. Внешний автоскалер видит среднее используемое в настоящее время процессора (не запрашивается) и не будет масштабироваться (не добавит еще один узел). Pod не будет запланирован.

    Масштабирование (удаление узла из кластера) всегда сложнее. Представьте, что у вас есть модуль с состоянием (с подключенным постоянным томом), и поскольку постоянные тома обычно являются ресурсами, которые относятся к определенной зоне доступности и не реплицируются в регионе, ваш пользовательский автоскалер удаляет узел с этим модулем, и планировщик не cможет запланировать его на другой узел, так как он ограничен единственной зоной доступности с вашим постоянным диском в нем. Pod снова застрял в состоянии ожидания.

    Сообщество широко использует cluster-autoscaler, который работает в вашем кластере и интегрирован с большинством API-интерфейсов большинства поставщиков общедоступных облаков, понимает все эти ограничения и будет масштабироваться в упомянутых случаях. Он также выяснит, может ли он корректно масштабироваться, не затрагивая какие-либо ограничения, которые мы установили, и сэкономит вам деньги на вычислениях.

    Не используя IAM / RBAC

    Не используйте пользователей IAM с постоянными секретами для машин и приложений, создавайте временные секреты с использованием ролей и учетных записей служб.

    Мы часто это видим – жесткое кодирование доступа и секретные ключи в конфигурации приложения, никогда не меняя секреты, когда у вас есть Cloud IAM под рукой. Используйте роли IAM и учетные записи служб вместо пользователей, где это необходимо.

    Пропустите kube2iam, перейдите непосредственно к ролям IAM для учетных записей служб, как описано в этом посте https://blog.pipetail.io/posts/2020-04-13-more-eks-tips/ .

    apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-app-role
  name: my-serviceaccount
  namespace: default

    Одна аннотация. Это было не так сложно?

    Также не предоставляйте учетные записи служб или профили экземпляров adminи cluster-adminразрешения, когда они не нужны. Это немного сложнее, особенно в k8s RBAC, но все же стоит усилий.

    Самостоятельное сродство c pods

    Запуск, например, 3-х реплик некоторого развертывания, узел отключается и все реплики с ним. А? Все реплики работали на одном узле? Разве Kubernetes не должен был быть волшебным и обеспечивать HA ?!

    Вы не можете ожидать, что планировщик kubernetes будет применять антиаффинные средства для ваших модулей. Вы должны определить их явно.

    // omitted for brevity
      labels:
        app: zk
// omitted for brevity
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: "app"
                    operator: In
                    values:
                    - zk
              topologyKey: "kubernetes.io/hostname"

    Вот и все. Это обеспечит планирование модулей на разные узлы (это проверяется только во время планирования, а не во время выполнения, следовательно, requiredDuringSchedulingIgnoredDuringExecution).

    Мы говорим о podAntiAffinity на разных именах узлов, а topologyKey: "kubernetes.io/hostname"не на разных зонах доступности. Если вам действительно нужен правильный HA, копайте глубже в этой теме.

    без подкупа бюджета

    Вы выполняете производственную нагрузку на kubernetes. Ваши узлы и кластер должны время от времени обновляться или выводиться из эксплуатации. PodDisruptionBudget (pdb) – это своего рода API для гарантий обслуживания между администраторами кластера и пользователями кластера.

    Убедитесь, что создали, pdbчтобы избежать ненужных перерывов в обслуживании из-за опустошения узлов.

    apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

    В качестве пользователя кластера вы говорите администраторам кластера: «эй, у меня здесь есть служба zookeeper, и независимо от того, что вам нужно делать, я бы хотел, чтобы по крайней мере 2 реплики были всегда доступны».

    Более подробно здесь, в этом посте https://blog.marekbartik.com/posts/2018-06-29_kubernetes-in-production-poddisruptionbudget/

    больше арендаторов или envs в общем кластере

    Пространства имен Kubernetes не обеспечивают какой-либо сильной изоляции .

    Люди, кажется, ожидают, что если они разделят рабочую нагрузку, не относящуюся к prod, к одному пространству имен и prod к пространству имен prod, то одна рабочая нагрузка никогда не повлияет на другую. Можно достичь некоторого уровня справедливости – запросов и пределов ресурсов, квот, приоритетов – и изоляции – сходства, допуски, порты (или выборки узлов) – для «физического» разделения рабочей нагрузки в плоскости данных, но это разделение довольно сложное.

    Если вам нужно иметь оба типа рабочих нагрузок в одном кластере, это будет достаточно сложно. Если вам это не нужно, а наличие другого кластера относительно дешево для вас (как в общедоступном облаке), поместите его в другой кластер, чтобы достичь гораздо более высокого уровня изоляции.

    externalTrafficPolicy: кластер

    При этом очень часто весь трафик направляется внутри кластера в службу NodePort, которая по умолчанию имеет externalTrafficPolicy: Cluster. Это означает, что NodePort открыт на каждом узле в кластере, так что вы можете использовать любой из них для связи с желаемой службой (набором модулей).

    Чаще всего фактические модули, на которые ориентирована служба NodePort, запускаются только на подмножестве узлов . Это означает, что если я общаюсь с узлом, на котором не запущен модуль, он перенаправит трафик на другой узел, что вызовет дополнительный сетевой скачок и увеличит задержку (если узлы находятся в разных AZ / центрах обработки данных, задержка может быть довольно высокой и к этому добавляется дополнительная стоимость).

    Настройка externalTrafficPolicy: Localслужбы kubernetes не будет открывать этот NodePort на каждом узле, а только на узлах, где на самом деле работают модули. Если вы используете внешний балансировщик нагрузки, который проверяет работоспособность своих конечных точек (как это делает AWS ELB ), он начнет отправлять трафик только на те узлы, куда он должен идти, улучшая вашу задержку, накладные расходы на вычисления, исходящие счета и работоспособность.

    Скорее всего, у вас есть что-то вроде traefik или nginx-ingress-controller , представленного как NodePort (или LoadBalancer, который также использует NodePort) для обработки маршрутизации вашего входящего http-трафика, и этот параметр может значительно уменьшить задержку при таких запросах.

    Кластеры + чрезмерное напряжение в плоскости управления

    Вы ушли от того, чтобы называть свои серверы Anton , HAL9000 и Colossus, чтобы генерировать случайные идентификаторы для своих узлов, но вы начали называть свой кластер по имени?

    Вы начали с Proof Of Concept с Kubernetes, назвали кластер «тестирование» и все еще используете его в продуктиве, и все боятся его трогать? (правдивая история)

    Pet clusters – это не весело, и вы можете время от времени рассматривать возможность удаления своего кластера, попрактиковаться в Аварийном восстановлении и позаботиться о своей панели управления. Бояться трогать панель управления – плохой знак.

    С другой стороны, трогать его слишком сильно тоже нехорошо. Когда со временем панель управления становится медленной , скорее всего, вы либо создаете много объектов, даже не подозревая об этом (очень часто при пользовании настройками по умолчанию, которые вы не меняете в конфигурационных / секретных файлах, и в итоге вы получаете тысячи объектов в плоскости управления) или вы постоянно очищаете и редактируете множество вещей из kube-api (для автоматического масштабирования, cicd, мониторинга, журналов событий, контроллеров и т. д.).

    Также проверьте свои управляемые kubernetes, предлагающие «SLA» / SLOs и гарантии. Поставщик может гарантировать доступность плоскости управления (или ее подкомпонентов), но не задержку p99 запросов, которые вы ему отправляете. Другими словами, вы можете сделать kubectl get nodesи получить правильный ответ в течение 10 минут, и это все еще не нарушает гарантию обслуживания.

    Бонус: используйте тег

    Это классика. Я чувствую, что в последнее время я не вижу этого очень часто, так как многие из нас слишком много обожглись, и мы перестали использовать :latestи начали прикалывать версии. Ура!

    У ECR есть отличная особенность неизменяемости тегов , которую обязательно стоит проверить.

    Резюме

    Не ожидайте, что все работает автоматически – Кубернетес – не серебряная пуля. Плохое приложение будет плохим приложением даже на kubernetes (возможно, даже хуже, чем плохое, на самом деле). Если вы не будете осторожны, вы можете столкнуться с большими сложностями, стрессом и медленным управлением и отсутствием стратегии DR. Не ожидайте многопользовательской аренды и высокой доступности. Потратьте некоторое время на то, чтобы сделать ваше приложение облачным.

  • Выявление узвимостей в процессе разработки

    Выявление узвимостей в процессе разработки

    Добавление интеграции SDLC и уровня оркестровки в AST решения, помогает объединить решения в интегрированную и простую в использовании платформу, разработанную для обеспечения организации целостным поиска уязвимостей программного обеспечения, призванную масштабировать и упростить автоматизацию AST. В результате это позволяет организации легко отслеживать, управлять и устранять риски безопасности. Этот слой крайне необходим для упрощения и централизованного управляемый потоком автоматизации, от сканирования до создания тикета. При поиске решений AST, убедитесь, что они имеют интеграцию с SDLC и слой оркестрации.

    Где встраивать решения AST в DevOps

    Ниже на странице показан тот же рисунок, что и на рисунке.  но с некоторыми различиями, добавлены различные решения AST.
    Эта картинка должна помочь организациям понять, где можно внедрить различные AST решения в этапы DevOps.

    Как видно на рисунке, решения AST должны быть встроены в этапы Dev, в то время как результат в Ops. Правильные решения AST для каждой стадии Dev выделены тонкими зелеными линиями вокруг различных этапов. Точки ниже выделяют точную стадию (или стадии) где решения AST лучше всего подходят и для Dev:

    • + SAST работает по всему CODE, CHECK-IN, BUILD, и этапам TEST / QA
    • + IAST работает на этапе TEST / QA
    • + SCA работает на этапах BUILD и TEST / QA
    • + DAST работает на этапе TEST / QA, но имеет ограничения, как упоминалось ранее.

    На рисунке управляемые сервисы, AppSec позволяют организациям передать AST на аутсорс третьей стороне, которая поможет внедрить процессы безопасности приложений, методы безопасного кодирования, тестирование безопасности и устранение уязвимостей.  Такие услуги помогут организациям, у которых нехватка внутренних ресурсов и опыта на начальных этапах внедрения безопасности в среду DevOps.
    Кроме того, на рисунке был добавлен новый термин (SCE), который не был рассмотрен ранее. SCE расшифровывается как Secure Coding Education и работает на этапах CODE DevOps. Далее рассмотрим SCE более детально.

    Secure Coding Education

    Ранее мы опровергли концепцию сдвига в отношении AST решения в DevOps. Однако сдвиг влево имеет смысл, для Secure Coding Education (SCE). Чем раньше вы обнаружите уязвимости программного обеспечения, тем проще и дешевле их устранить. Однако реальность такова, что значительный процент разработчиков не уверены в безопасности своих приложений, или мало что знают об уязвимостях и о том, как
    они созданы.

    Причина этому в том, что навыки разработчика измеряются скоростью и количеством функциональных ошибок в их коде, а не количеством
    уязвимости безопасности, которые они создают. Чтобы преодолеть это, организации должны понимаю, что им нужно предоставить своим разработчикам SCE и включить в их IDE как можно раньше. Проблема с традиционными методами обучения, такими как видеоуроки,
    периодическое обучение в классе и обязательные онлайн-курсы часто не дают результата для достижения безопасных методов кодирования, так как они являются теоретическими, а не практическими. Вся идея SCE заключается в повышении зрелости разработчиков в безопасности, что позволяет им принимать активное участие в разработка более безопасного кода. Разработчики, должны понимать, что безопасность
    их программного обеспечения, уменьшит повторяющиеся ошибки кодирования, и значительно уменьшить количество уязвимостей в программном обеспечении, которые необходимо устранить. Когда  с помощью AST обнаружена уязвимость, разработчики должны иметь возможность выделить уязвимость, перейдите к обучающему уроку специально об этом типе уязвимости, и узнать, как исправить уязвимость, и все время совершенствовать свои IDE.

    Поскольку DevSecOps означает больше, чем просто использование решений AST в процессах DevOps, давайте рассмотрим несколько более важных областей – автоматизации в DevOps в следующей статье.

  • Как проверить сайт на уязвимость

    Как проверить сайт на уязвимость

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

    В начале текущего года во Всемирной паутине насчитывалось около 1,75 миллиардов онлайн-ресурсов, большая часть которых уязвима к хакерским атакам. Несколько лет назад организацией под названием Web Application Security Consortium были проведены исследования, которые показали, что минимум 13% веб-страниц можно с легкостью взломать. В прошлом году данный анализ был проведен повторно, и по его результатам стало известно, что уязвимыми приложениями являются 19% от общего количества.

    Главные принципы хакерского проникновения в веб-систему

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

    Подобный взлом происходит по такой схеме:

    •   поиск уязвимости;
    •   проведение эксплоитов либо взятие готового специализированного бота;
    • поиск конкретной дыры на каждом сайте в определенном диапазоне и попытка ее эксплуатации.

    Поиск уязвимостей

    Перед тем как попытаться выполнить атаку какой-либо цели, очень важно собрать полноценную информацию о ней, а именно: проверить сайт на уязвимость. Для этого следует воспользоваться утилитой под названием WhatWeb. С ее помощь можно получить необходимые сведения про CMS, а также о ряде применяемых веб-инструментов.

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

    Какие виды CMS существуют

    Сегодня существует несколько популярных CMS, самые распространенные это:

    1.    “WordPress”.

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

    1.  «Joomla».

    Имеет собственный одноименный сканер, который называется «Joom Scan». Он установлен в большом количестве дистрибутивов для специалистов в сфере обеспечения безопасности. Поддерживает более агрессивный способ исследования предустановленных элементов. При помощи программы можно узнать о версии системы, обо всех уязвимостях и ссылках на эксплоиты, благодаря которым можно без проблем взломать сайт.

    Защита сайта от несанкционированного взлома

    Клиентам, владеющим сайтами на одной из популярных CMS и желающим обезопасить себя от несанкционированных хакерских атак, следует провести несколько действий. Сюда входит:

    •     отказ от установки утилит с непроверенных ресурсов;
    •   сведение на минимум количества плагинов;
    •   регулярное обновление программного обеспечения.

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

    В любом случае, предлагаем Вам не гадать, а сделать профессиональную проверку сайта на уязвимость. Наши специалисты уже 10 лет на страже безопасности веб-ресурсов. Обращайтесь!