Блог

  • CentOS Linux 8.1 (1911) как обновиться

    CentOS Linux 8.1 (1911) как обновиться

    Выпущена новая версия Linux 8.1 (1191). Это дистрибутив Linux, полученный из исходного кода RHEL (Red Hat Enterprise Linux) 8.1. CentOS был создан, когда Red Hat перестала предоставлять RHEL бесплатно. CentOS 8.1 дает полный контроль над своими пакетами программного обеспечения с открытым исходным кодом и полностью настроен для исследовательских нужд или для запуска высокопроизводительного веб-сайта без платы за лицензию. Давайте посмотрим, что нового в CentOS 8.1 (1911) и как обновить существующий сервер CentOS 8.0.1905 до 8.1.1911 с помощью командной строки.

    Доступен CentOS Linux 8 (1911)

    Из рассылки:

    Обновления, выпущенные с момента выпуска основной ветки разработки, публикуются для всех архитектур. Мы настоятельно рекомендуем каждому пользователю применять все обновления, включая контент, выпущенный сегодня, на вашей существующей CentOS Linux 8. Этот выпуск заменяет весь ранее выпущенный контент для CentOS Linux 8, и поэтому мы настоятельно рекомендуем всем пользователям обновить свои машины. Информация о различных стратегиях обновления и о том, как обращаться с устаревшим контентом, включена в Примечания к выпуску

    Как обновить до CentOS Linux 8.1 (1911)

    Сначала запишите версию CentOS Linux 8, введя следующую команду cat :

    cat /etc/centos-release

    Пример вывода:

    CentOS Linux выпуск 8.0.1905 (Core)

    Также найдите и запишите версию ядра Linux :

    uname -mrs

    Пример вывода:

    Linux 4.18.0-80.11.2.el8_0.x86_64 x86_64

    Как обновить CentOS 8 до 8.1

    Можно обновить существующий сервер CentOS Linux 8, просто выполнив следующую команду dnf или команду yum :

    sudo dnf update

    ИЛИ

    sudo yum update
    обновление centos
    Команда обновления CentOS Linux 8 (1911)

    В конце перезагрузите систему Linux :

    $ sudo shutdown -r now

    ИЛИ

    $ sudo reboot

    Верификация

    Убедитесь, что обновление прошло гладко с помощью [nixmd name = ”cat”] / grep command / egrep :

    $ uname -mrs
    $ cat /etc/centos-release
    $ dmesg | egrep -i 'err|warn|critical'
    $ sudo tail -f /var/log/https/access_log
    $ sudo tail -f /var/log/https/error_log

    Вывод

    Вы узнали, как обновить существующую CentOS Linux версии 8.0 до 8.1 (1191) с помощью командной строки. Также можно получить обновленный ISO для полной установки.

  • Как получить доступ к рабочему столу Windows пользователя, не зная его пароля

    Как получить доступ к рабочему столу Windows пользователя, не зная его пароля

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

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

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

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

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

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

    Во-первых, вам нужно скачать Sysinternals Suite или просто PsExec.exe. Затем вам нужно запустить PsExec из командной строки с повышенными привилегиями или из консоли PowerShell.

    • Запустите PsExec со следующим синтаксисом:
    1
    PSEXEC SID cmd.exe
    • Теперь запустите Taskmgr.exe из новой командной строки (убедитесь, что диспетчер задач еще не запущен).
    • Теперь перейдите на вкладку «Пользователи», щелкните правой кнопкой мыши сеанс пользователя и выберите “Подключиться”.

    И вот вы на рабочем столе пользователя, не зная его пароль.

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

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

  • Как идентифицировать медленные запросы в PostgreSQL

    Как идентифицировать медленные запросы в PostgreSQL

    Хорошо, допустим, Вы сделали свою работу действительно правильно:

    •     Нормализация / денормализация создала идеально сбалансированную схему
    •     Ограничения применяются тщательно
    •     Вы подумали об индексах, выбрали правильные столбцы на основе вашего фильтра и критериев заказа
    •     Ваши PL/pgSQL хранимые процедуры и триггерный код следуют рекомендациям
    •     Вы избежали очевидных ловушек, таких как разделение последовательностей на несколько таблиц
    •     Вы определили разделы, которые дают почти одинаковые размеры сегментов
    •     Сервер имеет правильный размер, IO является мощным
    •     Конфигурация PostgreSQL сделана вдумчиво.

    И все же, некоторые запросы медленные.

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

    Во-первых, вы должны спросить себя: что значит медленный в вашем контексте? Какое максимальное время отклика вы можете допустить в своем приложении или услуге? В веб-приложении время ответа 100 мс может быть слишком большим, тогда как вы можете быть очень счастливы, когда большой финансовый квартальный отчет выполняется менее 8 часов.

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

    log_min_duration_statement

    Когда вы знаете, какое максимальное время выполнения запроса приемлемо, вы можете указать PostgreSQL регистрировать операторы, которые занимают больше времени, добавив это в postgresql.conf:

    log_min_duration_statement=5000

    Это будет регистрировать все вызовы, которые занимают более 5 секунд.

    Чтобы активировать, попросите PostgreSQL повторно загрузить файл конфигурации в сеансе SQL:

    SELECT pg_reload_conf();

    Вы можете проверить это при выдаче

    SELECT pg_sleep(7.5);

    а затем посмотрите файл логов:

    2019-03-07 18:44:12.727 CET [31308] postgres@postgres LOG:  duration: 7515.906 ms  statement: SELECT pg_sleep(7.5);

    pg_stat_statements

    Это расширение PostgreSQL, которое а) необходимо загружать во время запуска процесса сервера и б) активировать как расширение.

    Для этого добавьте эту строку в postgresql.conf:

    shared_preload_libraries = 'pg_stat_statements'

    Затем расширение необходимо привязать к базе данных, где вы хотите, чтобы оно было активным, подключиться к базе данных и выполнить:

    CREATE EXTENSION pg_stat_statements;

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

             View "public.pg_stat_statements"
           Column        |       Type       | Collation | Nullable | Default
    ---------------------+------------------+-----------+----------+---------
     userid              | oid              |           |          |
     dbid                | oid              |           |          |
     queryid             | bigint           |           |          |
     query               | text             |           |          |
     calls               | bigint           |           |          |
     total_time          | double precision |           |          |
     min_time            | double precision |           |          |
     max_time            | double precision |           |          |
     mean_time           | double precision |           |          |
     stddev_time         | double precision |           |          |
     rows                | bigint           |           |          |
     shared_blks_hit     | bigint           |           |          |
     shared_blks_read    | bigint           |           |          |
     shared_blks_dirtied | bigint           |           |          |
     shared_blks_written | bigint           |           |          |
     local_blks_hit      | bigint           |           |          |
     local_blks_read     | bigint           |           |          |
     local_blks_dirtied  | bigint           |           |          |
     local_blks_written  | bigint           |           |          |
     temp_blks_read      | bigint           |           |          |
     temp_blks_written   | bigint           |           |          |
     blk_read_time       | double precision |           |          |
     blk_write_time      | double precision |           |          |
    

    Пример:

    select query,calls,total_time,min_time,max_time,mean_time,stddev_time,rows from pg_stat_statements order by mean_time desc;

    который дает (строка запроса сокращена):

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

    Вы также можете использовать это, чтобы получить представление о конкретной рабочей нагрузке. Например, если вы знаете, что проблема появляется вскоре после определенного события или времени, вы можете сбросить статистику непосредственно перед этим и запросить представление, когда возникли проблемные детали. Для этого просто вызовите pg_stat_statements_reset () до желаемого времени или события:

    SELECT pg_stat_statements_reset();

    Хотите оптимизировать базу данных на максимум – наши специалисты рады помочь!

  • Новая уязвимость в php-fpm nginx

    Новая уязвимость в php-fpm nginx

    Связка php-fpm nginx очень популярна в работе сайтов. Поэтому, мы решили разместить выдержку из журнала Хакер, по эксплуатации новой уязвимости в этой связке:

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

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

    Хотя здесь и имеется определенный список начальных условий, не стоит думать, что их не бывает в дикой природе. Совсем наоборот. Nginx — штука гибкая, и существует огромное количество заведомо уязвимых конфигов. Плюс ко всему разработчики любят копировать готовые настройки друг у друга, не проводя даже минимальный их анализ. Это тоже не прибавляет безопасности.

    • слову, дефолтный конфиг Ubuntu 18.04 от падения в пучину RCE отделяет всего одна строка — try_files $fastcgi_script_name =404;.

    уязвимость nginx

    Дефолтный конфиг fastcgi.conf для nginx в Ubuntu 18.04

    Если ее убрать, то получаем уязвимую среду. А это не такой уж и редкий случай. Представь, что nginx и PHP‐FPM находятся на разных машинах. Такая схема довольно часто встречается в продакшене.

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

    Что касается патча, то разработчики довольно быстро отреагировали на инцидент и залатали брешь. Но дистрибутивы PHP не так часто обновляются на серверах, поэтому в ближайшее время будет еще множество потенциально уязвимых продуктов. Так что не зевай, следи за обновлениями дистрибутивов и своевременно накатывай патчи! Особенно те, которые повышают безопасность. Обращайтесь office@itfb.com.ua, мы поможем защитить ваши системы.

     

  • Проверка и очистка сайта joomla от вирусов

    Проверка и очистка сайта joomla от вирусов

    1. Проверяем сайт на признаки взлома

    Чтобы не принять необычное поведение сайта за взлом, проверьте, что вы видите один или несколько из этих признаков:

    • Установленый плагин безопасности показывает предупреждение
    • Невозможно зайти в админ панель Joomla
    • Joomla сайт перенапрявляет на сторонние ресурсы или рекламу
    • На сайте появились неизвесные ссылки которых вы не добавляли
    • Вы видите внезапное увеличение посещаемости, это может быть перенаправлением спам-трафика через ваш сайт.
    • Сканирование сайта на Sucuri Site Check, Virus Total или 2ip  показывает проблемы
    • Гугл, Яндекс или другие поисковики пометили ваш сайт как небезопасный
    • Chrome и другие браузеры предупреждают посетителей о фишинге, вредоносном коде, подозрительной перелинковке и других опасных вещах на сайте
    • Хостинг отключил ваш сайт по причине вирусов или спам трафика

    Если у вас один или несколько из этих признаков и вы просканировали сайт в Sucuri Site Check, Virus Total и 2ip, которые что-то нашли, значит, пора читать инструкцию по лечению Joomla сайта.

    Специалисты компании ITFB помогут быстро очистить сайт от вирусов и устранить уязвимость.

    1. Делаем резервную копию сайта

    В Joomla нет своего инструмента для бекапа. Поэтому если у вас есть плагин Akeeba Backup или анагогичный можно сделать полный бекап сайта с его помошью и скачать его себе на компьютер.

    очистка joomla

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

    Cкачайте файлы сайта с сервера

    Зайдите на сервер через файл-менеджер на хостинге или по FTP и скачайте файлы Joomla с сервера.  Для подключения к серверу по FTP можно использовать программу FileZilla.удаление вируса

    Также убедитесь, что у вас включено отображение скрытых файлов. В каталоге Joomla находятся важные, но скрытые по умолчанию файлы. Убедитесь, что они попадут в бэкап. В FileZilla  эта настройка находится в Server — Force showing hidden files.

    Теперь выделите все содержимое и скопируйте иго в созданную папку на компьютере.

    Скачайте бекап базы данных сайта

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

    Для бекапа базы данных, зайдите на хостинг и найдите раздел База данных, Database, MySQL или что-то подобное. Выберите нужную базу данных и откройте ее.

    Если вам не извесно, какая база данных относится к вашему сайту, откройте файл сonfiguration.php и посмотрите имя базы данных в этих строках:вирус джумла

    Зачастую для управления базой данных сайта используется приложение phpMyAdmin.

    Выберите базу вашего сайта и нажмите на Export в верхней вкладке.удаление вируса с сайта

    Здесь у вас есть 2 варианта:

    Первый вариант — оставить все как есть и нажать Go. После этого начнется загрузка файла с вашей базой данных.

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

    Второй вариант — выбрать Custom, в котором есть дополнительные настройки. Этот способ более предпочтителен, если у вас большая база данных, потому что этот способ сжимает данные перед скачиванием. Это значительно ускорит создание и скачивание бэкапа.

    В разделе Format выберите SQL. В разделе Tables вы можете выбрать, какие таблицы включить в бэкап.очистка от вирусов джумла

    В разделе Output выберите метод сжатия файла базы данных, zip или gzip.

    В Formatspecific options оставляем настройки по умолчанию.

    В разделе Object creation options поставьте галочку Add DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT / TRIGGER statement. Эта настройка удалит существующие таблицы во время восстановления базы данных.очистка joomla от вирусов

    Восстанавливаем и очищаем Joomla

    Хорошим вариантом будет обновление Joomla на свежую версию. Можно через админ консоль.

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

    – Установить свежую копию Joomla, изменяем пароли всех администраторов. Проверяем базу на наличие лишних юзеров.

    – Не забываем обновить Шаблоны и установить плагины.

    [sociallocker]

    Если вдруг у нас нету доступа в админ консоль, но есть доступ по FTP.

    1. Делаем резервную копию всех файлов сайта себе на компьютер.
    2. Полностью удаляем файлы сайта с сервера.
    3. Устанавливаем свежую версию Joomla на сервер
    4. Разворачиваем копию Базы данных
    5. Копируем папку /images и папку с активным шаблоном. Если вы пользуетесь дочерным шаблоном темой то скопируйте обе папки.
    6. Переносим настройки связи с базой данных из старого файла configuration.php в новый.
    7. Проверяем скачаный сайт одним или лучше несколькими антивирусами по очереди:
    • Ai-bolit
    • McAfee
    • ClamAV
    • ImunifyAV
    • Virusdie
    • Web CureIt!

    Настраиваем базовую безопасность с помощью “RSFirewall!” или “Admin Tools” или с аналогичными плагинами. Не забываем ограничить количество попыток входов в админку. Так называемые Brute force attack.

    защита сайта joomla

    [/sociallocker]

  • 10 практических рекомендаций по безопасности образов Docker

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

    Рекомендации по безопасности образов Docker

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

    1.    Предпочитайте базовые образы наименьшего размера. Наиболее часто началом проектов является определение базового образа контейнера Docker. Большинство из наиболее востребованных являются оснащенными образами, которые отличаются наличием множества уязвимостей.
    2.   Root права пользователей. С целью защиты следует включить группу в образе Docker, предназначенную для приложений. Благодаря этому возможно обеспечение информационной безопасности Docker.
    3. Проверка образов с целью избегания атак. За счет возможного взлома реестра учетной записи руководителя компании не исключена подмена образа. Благодаря настройкам Docker имеется возможность исключить подобную вероятность за счет проверки подлинности и особенностей происхождения.
    4.   Поиск, исправление вероятных уязвимостей в компонентах, которые используют открытый исходный код.
    5.  Не следует оставлять уязвимые данные в образах Docker. В редких случаях в процессе создания каких-либо приложений требуются секретные данные. Решением может стать использование многоэтапных сборок, за счет чего вы сможете манипулировать секретами.
    6.  Применение фиксированных тегов, которые, в свою очередь, представляют собой варианты одинаковых образов.
    7.   Применение COPY в качестве замены ADD. Несмотря на то, что команды являются во многом похожими по своей природе, они имеют функциональные отличия.
    8.  Применение меток метаданных. Благодаря этому значительно упрощается для пользователей процесс, который связан с ознакомлением со всеми особенностями использования образов.
    9.  Использование многоэтапных сборок. При создании различных приложений параллельно автоматически разрабатывается множество артефактов, которые необходимы при сборке. Из-за этого значительно увеличивается площадь атаки. В данном случае поможет приложение Golang, которое способно осуществлять включение исключительно чистых образов.
    10.   Использование линтера с целью предотвращения часто встречающихся ошибок. Благодаря этому устанавливаются новейшие практические рекомендации, которые пользователи могут применять в автоматическом режиме.

    Обращение к специалистам по обеспечению безопасности Docker

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

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

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

  • Переход с Terraform на CloudFormation

    Хранение информации на серверах и локальных компьютерах постепенно теряет свою актуальность. Многие предприятия предпочитают миграцию инфраструктуры в облако. Крупные виртуальные площадки, такие как Google, Amazon, Microsoft, Huawei, предоставляют услуги по хранению данных. Компании предлагают удобные условия использования и сохранность информации.

    Осуществить перенос можно с помощью грамотных специалистов и инструментов управления. К наиболее распространенным утилитам относятся Terraform и CloudFormation. Разберем каждый из них, и поймем, имеет ли смысл совершать переход с одного на другой.

    Миграция инфраструктуры в облако: плюсы и минусы

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

    Миграция в облако имеет следующие преимущества:

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

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

    Для этой цели используют один из двух наиболее популярных инструментов Terraform и CloudFormation.

    Terraform, для чего нужна утилита

    Наиболее популярная и востребованная утилита Terraform. Для чего она нужна и стоит ли переходить на CloudFormation? Все зависит от целей потребителя.

    Эти инструменты используют для создания и управления облачной инфраструктурой. 

    Основные достоинства Terraform.

    1.   Главное преимущество Terraform – использование возможно на базе любых облачных провайдеров. То есть нет привязки к AWS, и можно пользоваться любой удобной виртуальной платформой, будь то Google, Microsoft или тот же Amazon.
    2.   Есть возможность нескольких вариантов бэкенда, что весьма удобно, ведь есть возможность самостоятельно контролировать рабочие процессы.
    3.   Terraform позволяет видеть любые изменения.
    4.   В отличие от CloudFormation, с Terraform можно импортировать ресурсы, сделанные руками. Вам не придется все переделывать, он сам способен стягивать информацию и преображать ее в код.

    Это основные моменты, отличающие Terraform. Рассмотрим преимущества CloudFormation.

    Что собой представляет Сloudformation AWS

    Сloudformation создает единые шаблоны, позволяющие смоделировать всю инфраструктуру с помощью текстового файла.

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

    Каждую новую версию утилиты AWS старательно тестируют, и только потом выпускают в общественное пользование.

    Пользователи отмечают, что Сloudformation сложнее в использовании, чем Terraform. Совершая переход от одного к другому, они зачастую возвращаются к более удобному инструменту – Terraform.

     

     

  • Со мной такое не случится

    Со мной такое не случится

    Мы предлагаем своим клиентам построения отказоустойчивых решений с проектированием и реализацией drp плана, на что в большинстве случаев слышим ответ: Зачем мне лишние растраты, со мной такого не случится.

    А лишние ли они?

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

    Нам было крайне не приятно, что несколько сайтов клиентов, не были доступны, из-за разборок владельцев хостинга Айхор, и мы конечно же “подумали про себя, мы же предупреждали))”.

    Что произошло?

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

    • Клиенты потеряли трафик, простой в 30 часов дал знать падением трафика на 30-40% из за пессимизации
    • Клиенты могут попасть под санкции поисковых систем, возможно даже получить бан
    • Потеря новогодних продаж, для интернет магазинов простой в преддверии Нового года, самого пика продаж не может остаться не замеченным
    • В то время как все готовятся к празднику, пострадавшие клиенты восстанавливают работу своих ресурсов
    • Убытки и не полученная прибыль клиентов вот результат разборки владельцев Айхор

    Вывод из-за ругни владельцев хостинга пострадало множество клиентов.

    Вы уверены, что с Вами такого не случится?

    Факапы случаются и у AWS, Hetzner и не только. Не нужно наедятся на авторитет того или иного хостинга. Нужно быть готовыми ко всему. Поэтому DRP план должен быть разработан заранее.

    • Хранить бэкапы нужно всегда на удаленном сервере, и желательно на другом хостинге
    • Иметь запасную площадку, для холодного или горячего резерва
    • Строить отказоустойчивые решения, с распределенными системами
    • Разработать свой план аварийного восстановления, проводит его регулярные проверки и актуализацию

    Лучше проблему предупредить, чем решать её последствия.

    Обращайтесь office@itfb.com.ua, поможем подобрать оптимальное решение именно для Вашего бизнеса.

  • План аварийного восстановления − уверенность в завтрашнем дне

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

    Что такое drp планирование

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

    С помощью ДРП можно избежать неопределенных действий при возникновении непредвиденных ситуаций. А также планирование поможет разобраться в собственных бизнес-процессах и системах IT.

    DRP план: примеры использования

    Drp план: пример из нескольких этапов:

    1.    Анализ возможных рисков и воздействия на бизнес. Оцениваются потери от простоя, определяется зависимость от оборудования, главных сотрудников, IT, коммуникаций и других факторов. Аналитики прогнозируют возможный процент ущерба и вероятности. Формируют бюджет на защиту. В итоге содержание резервного сервера с полным копированием может оказаться экономически выгоднее, чем частые кратковременные отказы систем.
    2.    Аудит текущей защиты. Цель процесса заключается в исследовании слабых мест и составлении плана дальнейших действий для их защищенности, чтобы риски свести к минимуму. Возможно, нужно устранить какие-то факторы сразу без существенных потерь.
    3.   Разработка техники обеспечения непрерывности рабочего процесса. Подразумевает определение организационных и технических процессов, которые повышают готовность функционирования компании в режиме непредвиденных ситуаций.
    4.  Составление drp плана восстановления. Он заключается в распределении должностей: кто на себя берет какие задачи в чрезвычайных ситуациях, что кому и когда делать во избежание паники.
    5.  Обучение по плану. Желательно проводить каждый год. Актуализацию планов необходимо проходить раз в квартал. Компания всегда должна быть достойно подготовлена к разным непредвиденным обстоятельствам.

    С чего начать дрп план

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

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

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

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

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

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

  • DevOps будущего: что изменится и как это повлияет на профессию

    DevOps будущего: что изменится и как это повлияет на профессию

    Инновации развиваются очень быстро, постоянно появляются новые технологии, меняющие контекст, в котором мы работаем. Соответственно, в таком динамичной среде нельзя стоять на месте – нужно непрерывно изучать новое и развиваться. В то же время важно правильно определить, на какую технологию сделать ставку сегодня, чтобы быть успешным завтра. Это в определенной степени лотерея. Теперь побеждают те, кто 5 лет назад поставил на Kubernetes, а не на Docker Swarm, или выбрал Azure вместо Oracle Cloud.

    Я как директор решаю это не только для себя, но и для компании: в какие технологии нам инвестировать, в каком направлении развивать экспертов компании и что предлагать клиентам.

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

    С чего все начиналось и как эволюционировала роль Клауда

    Краткий флэшбэк в эволюцию Клауд. Pre-Cloud – олдскул: серверы, роутеры, СЗД. Работаем с этим сами – устанавливаем ОС, получаем библиотеки и платформы, разворачиваем епликейшены, конфигурируем и автоматизируем. Дальше – интереснее.

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

    Cloud 0 – в некоторых хостинг-компаний появляется идея продавать реальные серверы, а виртуальные, обеспечивая всю необходимую автоматизацию и работу по управлению инфраструктурой. Мы видим зарождение того, что в будущем получит название IaaS (Infrastructure as a Service). Но тогдашнему сервиса еще далеко до того, чтобы называться Клауд-провайдером.

    Cloud 1.0 – взлет Клауд-платформ. Появилось понимание, что большинство компаний используют те же ОС, платформы и фреймворки (Linux, Apache, PHP и т.д.). Это означает, что их можно автоматизировать, а инструменты для использования этих платформ – продавать как сервис. Появляются PaaS (Platforms as a Service), развивается тренд на использование публичных Клаудов. Инженеры получают новые инструменты для работы с платформами без необходимости разворачивать и поддерживать их самостоятельно. Объем рутинной технической работы становится еще меньше. Акцент в работе DevOps-инженера смещается на настройку платформы, наладка и развертывания решения на этой платформе, оптимизацию использования ресурсов, контроль за тем, насколько быстрым, понятным, гибким является весь процесс.

    Cloud 2.0 – автоматизация распространяется не только на платформы, но и на некоторые традиционные сервисы (email, queues). Нам больше не надо думать об их развертывании, управлении ими и их масштабировании, поскольку появляется такой концепт, как Software as a Service (SaaS). Он меняет парадигму в сторону отказа от традиционного биллинга за серверные ресурсы (CPU / RAM / HDD) к оплате абонемента на сервис и использованных ресурсов епликейшен-уровня по размеру обработанных данных или количеством транзакций.

    День Х – 7 июня 2014 года – первый публичный релиз Kubernetes. Черный день в истории Docker Swarm. Начинается эра Клауд-контейнеров, когда на смену традиционным виртуальным машинам для развертывания епликейшенов приходят контейнеры. Провайдеры очень быстро выпускают свои managed-решения для развертывания Kubernetes кластеров и управления ими. Появляются те поколения Клауд, которыми мы активно пользуемся сейчас.

    Cloud 2.5 – оркестраторы для контейнеров развиваются очень активно как ответ на установление глобального тренда на переход на микросервисну архитектуру в построении епликейшенов. Возникают Containers as a Service, позволяющие развернуть комплексную продакшен-архитектуру в Клауде всего за несколько часов или дней, в отличие от недель или месяцев, необходимых раньше.

    Cloud 3.0 – Functions as a Service (FaaS) – ответ на следующий этап эволюции, когда микросервисы становятся такими мелкими, что каждый из них отвечает за конкретную функцию. В то же время каждая функция полностью изолирована от другой. Соответственно, епликейшен разворачивается как ряд отдельных функций, каждую из которых можно привязать к другой или к любому ивента в системе или инфраструктуре.

    Как в свое время CaaS стал ответом на появление микросервиснои архитектуры, FaaS – ответ на дальнейшую эволюцию этой архитектуры и появление функций.

    Как эволюция Клауд уже изменила DevOps

    Когда мы располагали только серверы и даже когда появилась виртуализация, 80% времени DevOps-инженера шло на разработку и автоматизацию и только 20% – на процессы и конфигурацию платформы.

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

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

    Что происходит теперь

    По состоянию на 2019 Клауд – это must-have для энтерпрайз-компаний. 85% из них уже используют AWS или планируют перейти на них в следующем году. Немного меньший процент покрывают Azure, GCP. Кроме этого, доля Serverless, Container as a Service за год выросла на 40-50%. В наше время одна из трех компаний активно использует Serverless в продакшене, еще одна из трех – Container as a Service. Machine learning, IoT также растут, и за последующие 2-3 года доля этих технологий увеличится в два-три раза.

    По данным State of the Cloud Report 2019.

    Что дальше

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

    Service mesh

    Service mesh позволит эффективно управлять глобальными распределенными микросервиснимы (global distributed microservices) решениями на базе Kubernetes-платформы, которые продолжат стремительно развиваться в ближайшие годы. По данным исследований Gartner и IDC, в 2020 году все компании, которые применяют глобальную микросервисну архитектуру в продакшене,  будут использовать Service mesh. Время покажет, какие конкретные инструменты выигрывают. Теперь лидирует Istio, второй по популярности – Linkerd, но это еще может измениться с выходом на рынок продуктов от таких гигантов, как HashiCorp, Red Hat и VMware.

    Гибридные мультиклауды и Distributed clouds

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

    Многие Энтерпрайз рассматривают применение нескольких Клаудов – не только AWS, но также Azure, GCP и других, например, Alibaba Cloud, который так же быстро развивается в Азии, как и AWS в Северной Америке.

    Однако неэффективно иметь 5 различных команд, инструментов, процессов и подходов, чтобы разворачивать тот же епликейшен для различных Клауд-сред. Поэтому энтерпрайз-компании обращают все больше внимания на платформы, которые унифицировали бы управление ими и оказывали бы инженерам один user experience. Поэтому стремительно развиваются такие платформы, как Pivotal и OpenShift. В ближайшее время эта тенденция не только сохранится, но и усилится.

    Everything as a Service (XaaS)

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

    Эта тенденция сохранится и в ближайшем будущем количество платформ, которыми нужно будет управлять вручную, уменьшится до абсолютного минимума. Все превратится в managed-сервисы. Упростится интеграция таких сервисов между собой. Исчезнет необходимость в автоматизации и развертывании в таком виде, как мы это делали раньше. Custom development занимать минимальную долю нашего рабочего Лоуд.

    Containers, Serverless, ML, IoT

    До 2021 года Containers, Serverless удвоят свои показатели. Это означает, что 3 из 4 компаний будут их использовать. Использование ML, IoT возрастет втрое. Соответственно, инженерам, которые не хотят потерять свою работу за несколько лет, стоит это изучать.

    DataOps, MLOps, IoTOps

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

    Predictive CICD and engineering performance

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

    Казалось бы, Predictive CICD облегчит жизнь самим разработчикам, но не DevOps-инженерам. Хотя на самом деле это win-win для всех нас. Устранение человеческого фактора по написанию кода, где лишняя запятая может нарушить всю систему, – один из основных аспектов улучшения общей производительности проекта. И это значительный шаг вперед. Думаю, на это понадобится года 3-4, поскольку появляются новые и новые инструменты, позволяющие лучше собирать и обрабатывать данные, улучшается ML, что в конце приведет к полной автоматизации.

    AIOps

    В последующие несколько лет зародится новое течение AIOps, которое соединит в себе функционал big data и ML, чтобы частично или полностью освободить инженеров от тех операционных задач, которые они еще выполняют. Речь идет о availability- и performance-мониторинге, корреляции и анализе ивентов, менеджменте и автоматизации ИТ-сервисов. Решение по расширению или сужению инфраструктуры, переразворачиванию, перезагрузке сервиса, миграции платформа принимает уже автоматически, без участия инженеров.

     

    Рассмотрим на конкретном примере. К чему может привести час простоя Facebook, Instagram или Netflix? К значительным финансовым потерям, снижениюцены акций, потери лояльности пользователей. А это может произойти даже через мелкую ошибку. Но что бы ни привело к неисправности, инженер должен осуществить работу, чтобы отыскать ее причину, а потом еще потратить время, чтобы ее устранить. А если это случается ночью, то к этому добавляется и время на то, чтобы он проснулся и включил компьютер. Решения, основанные на AI, все это выполнят в секунду.

    DevOps будущего. Перспектива на 5+ лет

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

    Так, традиционный DevOps в нынешнем понимании постепенно исчезнет. Но появляться новые зоны ответственности надо будет оптимизировать процессы, подняться на уровень выше AI и работать более как data scientist, ML-инженер, анализировать данные.

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

    Основной задачей DevOps-инженера станет собрать все элементы и объединить их в оптимизированную систему, чтобы обеспечить ее максимально эффективную работу. Это предполагает понимание того, как развернуть епликейшен и платформу, построить процессы и объединить их между собой так, чтобы избежать неисправностей. А как мы можем проверить, что этот прогресс действительно происходит? Без измерений и конкретных цифр – никак. Соответственно, надо будет измерять, анализировать и четко понимать все процессы. Работа DevOps-инженера будет тесно связана со сбором и анализом информации о работе целых платформ.

    Мы уже начинаем это делать, и в ближайшее время это еще активнее набирать обороты. Те компании, которые сейчас работают по старой схеме, когда есть необходимость собственноручно писать много кода, постепенно также будут переходить на новую модель. С приходом в Клауд даже тех вертикалей, которые сейчас отстают (Healthcare и финансы), потребность в разработке и использовании кастомных решений для автоматизации исчезает. Соответственно, останутся процессы и конфигурация. А для тех, кто теперь впереди, добавятся ML и AI, которые помогут им работать с данными, научат их системы автоматически принимать решение на базе метрик и данных.

    Предсказания на следующие 10 лет от Enterprise: в 80% компаний традиционная ИТ-часть организации, к которой принадлежит DevOps, уменьшится до минимального уровня. Operations- и development-специалисты будут работать с платформами, данными, аналитикой. Людей в компании, которые будут лезть в платформу, дописывать и подправлять, практически не останется.

    К нам обращаются многие компании, которые на шаг отстают от этих тенденций, за помощью в прохождении такой трансформации. То есть все больше компаний начинают осознавать, насколько это важно. Тех, кто находится на этапах Cloud 0 или Cloud 1.0, мы переводим сразу на Cloud 3.0. Соответственно, рывок вперед происходит быстрыми темпами.

    Те компании, которые эти этапы уже прошли, обращаются с точечными запросами, например помочь им настроить кост-менеджмент в Клауде или помочь построить новую платформу на базе FaaS / XaaS.

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