Технические долги

Большинство компаний сталкиваются с огромным количеством технических «долгов» во время миграции в облако.
В этой статье мы рассмотрим 5 путей как DevOps может помочь их решить.

Что такое технический «долг»?

Технический «долг» – не оптимальные технические решения, накопленные за все время жизни приложения. Такие вещи становится все сложнее и сложнее исправлять и в конце концов эти инициативы просто останавливаются.

К примеру, плохо описанный процесс управления состоянием (state management) может сильно усложнить горизонтальное расширение. Перед тем как расширять структуру вам придется переписать ту часть кода, которая отвечает за управление состоянием. Это и называют техническим «долгом».

Так же технические «долги» встречаются и в операционной деятельности.
Все еще работаете на Windows Server 2008, or Ubuntu 11.04 которые не поддерживаются производителем?
Не установили последний патч по безопасности? Это и есть технический «долг».

Как DevOps может помочь?

Создайте DevOps команду

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

Простые советы для борьбы с техническими «долгами»

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

Во время работы над продуктом помечайте (в Jira, Azure DevOps или Git) не оптимальные элементы как «techDebt». И выделять время в каждом спринте на эти задачи.
Мы советуем начать с 20% времени, выделяемого на спринт.

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

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

Построение общих сервисов самообслуживания

Все чаще компании создают общие сервисы для поддержки команд ответственных за продукты. Платформы основанные, на таких сервисах помогают избегать технических «долгов» при построении цепочек компонентов. Такие сервисы должны быть созданы в соответствии с запросами разработчиков и лучшими практиками для создания таких систем. Они могут быть, как сторонними SaaS-решениями, так и полностью собственными решениями.

Хорошая платформа — это общее дело. Она не должна быть черным ящиком для разработчиков, поэтому построение платформы стоит начать с изучения опыта открытых проектов и возможности применить эти решения в ваших внутренних платформах.

Немного о InnerSource

В определении InnerSource от InnerSource Commons говорится «консолидирует опыт развития open source решений для помощи внутреннего развития компании».
Команды, работающие с платформой, должны быть ключевой точкой изменений и быть готовым к ним. Репозитории с кодом должны быть общедоступны и любой желающий может внести изменения после согласования с управляющей командой.

Автоматизация

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

Как автоматизация может помочь с техническим «долгом»

Для примера возьмем процесс управления инфраструктурой и на его примере рассмотрим, как «инфраструктура как код» и «конфигурация как код» помогут нам в борьбе с техническим «долгом».

Несовместимые системы — это наиболее часто встречающийся вариант технического «долга». Когда ваше приложение работает в среде разработки, но не работает ни в препроде ни в проде чаще всего причиной будет несовместимость систем. Это могут быть как настройки ОС или приложения, так и тысячи межсервисных настроек, с которыми работает приложение. И то время, которое вы тратите на устранение этой проблемы и есть стоимость вашего технического «долга».

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

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

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

Контейнеры для упрощения внедрения и управления приложением

Что такое контейнеры и как они могут помочь?

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

Как и с инфраструктурным менеджментом, мобильность, которую дают контейнеры, может облегчить буквально все. Инструмент для оркестрации контейнеров, к примеру Kubernetes
позволяет автоматизировать систему жизненных циклов контейнеров. Это дает возможность DevOps команде не отвлекаться на операционные задачи, а заниматься более высоко уровневыми задачами (архитектура приложения и тд.)

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

Использование DevOps для построения API-ориентированной модели

Модель с использованием микросервисов это один из возможных вариантов реализации API-центрированной модели. Глава Amazon Джеф Безос поставил задачу своим сотрудникам пользоваться только API при взаимодействии с системой под угрозой увольнения.
Конечно, в вашей организации все может быть не так сурово. Тем не менее поощрение команды работать с API четко определенных версий, это хороший метод для ухода от технических «долгов». Чаще всего «долги» копятся из-за разных методов доступа приложений к сервисам и данным, которые не соответствуют друг другу. К примеру, команда А читает данные из таблицы созданной командой Б. И если команда Б поменяет схему для своих нужд, то этим они непреднамеренно нарушат интеграцию с приложением команды А.

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

Системы DevOps, к примеру CI/CD практика непрерывной интеграции и непрерывного развертывания кода обеспечивает сквозную прослеживаемость от юзер стори до реализации, а также позволяет разработчикам работать быстрее с меньшими рисками и с меньшими техническими долгами.
Если вы контролируете и помечаете места с техническими «долгами», как обсуждалось ранее, вы увидите результат достаточно быстро. А автоматизация процесса поможет сконцентрироваться на нуждах потребителя.

Практикум по SQL. Интервью с Юлией Шапошниковой и Антоном Помелило

Юлия, как пришла идея провести практикум по SQL? Какие цели и задачи вы перед собой ставили?

— Идея проводить обучение не новая. У нас уже был опыт проведения SQL обучения, но немного в другом формате. В этот раз мы запустили «гибридное» обучение (офлайн и онлайн). Я считаю, что ценностью данного курса стали именно практические занятия с куратором.

Мы тесно работали в коллаборации с Точкой Кипения ЮФУ. Все практические занятия проходили именно там. Я хотела бы выразить благодарность Центру карьеры ЮФУ за предоставление площадки для проведения нашего обучающего практикума по SQL.

Цель данного обучения — дать студентам тот необходимый минимум знаний, который нужен для того, чтобы пройти собеседование и трудоустроиться в нашу компанию на такие позиции как: BI разработчик, ETL разработчик, Консультант-разработчик ERP-систем, PL/SQL Разработчик и аналитик. На все эти вакансии основным требованием является знание SQL.

Юлия, сколько заявок на участие было подано и сколько человек отобрали в итоге? По каким критериям вы отбирали студентов на практикум?

— Набрали необходимое количество учеников чуть меньше чем за две недели. Мы и сами не ожидали такого большого количества откликов. Всего было подано больше 60 заявок, причем откликались люди даже из других городов. Желающих было довольно много, но мы решили, что для продуктивного обучения группа должна быть не более 15 человек. В итоге мы отобрали необходимое количество учеников. 13  человек дошли до конца.

Антон, По какому принципу составлялась программа обучения?

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

Антон, Вы были руководителем курса, расскажите, как проходило обучение, в каком формате?

— Обучение проходило в комбинированной форме (в онлайн и офлайн режиме). Материал программы был рассчитан на 150+ часов, на занятие в классе было выделено 40 часов (10 занятий по 4 часа).

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

В классе мы вместе разбирали основные моменты из тем, которые были заданы в качестве домашнего задания, и приступали к решению практики на эти темы. Поскольку наш курс назывался “Практикум по SQL”, основной задачей было научить ребят писать код на SQL, а основной разбор теории проходил вне стен аудитории.

Антон, в чем, на ваш взгляд, основное отличие нашего курса SQL от других?
— На мой взгляд, основным отличием нашего курса является то, что мы не пытались просто дать сухую теорию, а делали акцент на практику. Во многих практических задачах, которые мы разбирали в классе, были спрятаны “ловушки”, специально допущены ошибки в данных.

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

Юлия, Антон, Вы довольны результатами практикума?

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

— (Юлия) Да, результатами обучения мы довольны. Мне кажется, мы справились с поставленной задачей. К нам в компанию пришли работать 8 человек!

Юлия, Планируете еще проводить практикум по SQL или другим направлениям IT?

— Да, безусловно, мы планируем продолжать обучение в таком формате. Скорее всего немного поменяются требования. На следующий курс мы бы хотели набрать ребят со знанием английского языка. Что касается других направлений,  у нас практически в каждом отделе есть свое внутреннее обучение с наставником. Речь идет о студентах последних курсов и выпускниках ВУЗов, которые успешно прошли техническое собеседование. Они являются нашими сотрудниками и получают заработную плату.

Антон, что порекомендовали бы потенциальным ученикам / кандидатам?
— Подтянуть знания английского языка, пусть не разговорного, но хотя бы умение читать. Это крайне желательно, поскольку официальная документация по языку SQL полностью на английском языке.

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

Отзывы учеников:

Миграция данных из коммерческих СУБД в СУБД PostgreSQL

Задачи, решаемые при миграции данных из коммерческих СУБД в PostgreSQL?

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

Повышение гибкости: PostgreSQL имеет лицензию с открытым исходным кодом и легко доступен у поставщиков облачного хранения, включая AWS.

Улучшение настраиваемости: поскольку PostgreSQL имеет открытый исходный код, существует бесчисленное множество расширений и надстроек, которые могут заметно улучшить производительность базы данных.

Какие преимущества есть у PostgreSQL перед коммерческими СУБД?

Прикладное программирование:

Коммерческие СУБД и PostgreSQL предоставляют API-приложение для связи с базой данных. Однако PostgreSQL является Open Source, поэтому разработчики могут напрямую получать доступ к любому компоненту PostgreSQL, просто включив файл заголовка в свой проект.

Аутентификация:

Коммерческие СУБД имеют встроенную систему аутентификации. PostgreSQL же использует host-based аутентификацию и, следовательно, может поддерживать широкий спектр методов аутентификации. Это обеспечивает большую гибкость аутентификации и возможность делегировать процесс.

Расширяемость:

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

Какие преимущества есть у PostgreSQL?

Языки:

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

Локализация:

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

Производительность:

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

Масштабируемость:

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

Фазы миграции данных с коммерческих СУБД в PostgreSQL

Миграция данных состоит из следующих этапов:

  • Аудит системы (оценка совместимости, архитектуры и кода приложения)
  • Принятие решения на основе Аудита
  • Развертывание стенда для миграции
  • Конвертация данных и кода
  • Миграция схемы
  • Тестирование функциональности и оптимизация структур хранения и кода
  • Тестирование производительности и её оптимизация
  • Принятие решения о миграции
  • Миграция данных
  • Техническая поддержка Системы после Миграции

Услуги поддержки СУБД Oracle

Выбирая сервис поддержки СУБД Oracle от нашей компании Вы получите:

Наш сервис удаленной поддержки помогает достичь бесперебойной работы Клиентских СУБД Oracle и свести к минимуму сбои и простои систем.

Наши преимущества:

  • 24х7 Удаленная поддержка

Выделенная команда опытных инженеров следит за Вашей инфраструктурой 24 часа в сутки.

  • Не нужно держать в штате собственный штат администраторов баз данных.

Сократите затраты без потери качества поддержки

  • Планируйте развитие системы

Стройте прогноз по увеличению и росту нагрузки, добавлению мощностей и ресурсов

  • Выделенный аккаунт менеджер

Единая точка входа по всем возникающим вопросам. Кто координирует, планирует и контролирует всю активность на ваших системах. Увеличивая скорость реакции и коммуникации.

Как мы работаем (принцип работы):

Работаем с уже готовой архитектурой или помогаем построить с нуля

  • Мы выполняем весь комплекс задач

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

  • Оптимизация производительности

Опытные инженеры могут настроить производительность работы СУБД через партиционирование таблиц, оптимизацию запросов, создание индексов, пересмотр настроек параметров СУДБ и др

  • Мониторинг систем в режиме 24х7

В режиме реального времени наша команда следит за компонентами системы, такими как CPU, память, соединения, репликация и др. Как только метрики выходят за пороговые значения, мы начинаем действовать.

  • Планируем активности заранее

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

Что входит в услуги поддержки СУБД:

Мониторинг

  • Мониторинг 24 на 7
  • Подключение инструментов автоматического мониторинга
  • Реакция на инциденты в режиме реального времени
  • Разработка расширенных метрик мониторинга
  • Проактивная реакция
  • Разработка эскалационных процедур
  • Мониторинг операционных систем
  • Работа с Oracle Support[/su_list]

Регламентные работы и настройка резервного копирования

  • Установка обновлений (Patches)
  • Переход на новые версии (Upgrades)
  • Планирование отказоустойчивости и аварийного восстановления
  • Настройка политик резервного копирования
  • Резервное копирование и восстановление из копий
  • Поддержка решений высокой доступности
  • Экспертиза в работе  с ASM, RAC, Dataguard, Golden Gate
  • Опыт в работе с RMAN, DBCA, DUA, NetCA, OUI
  • Знания инструментов Advanced Compression и Enterprise Manager
  • Планирование масштабируемости и балансировки нагрузки
  • Анализ поведения нагрузки
  • Восстановление к точке во времени
  • Внедрение лучших практик
  • Установка экземпляров Oracle
  • Установка тестовых Сред
  • Создание StandBy для чтения в продуктивной среде
  • Установка гетерогенного подключения для связи с другими СУБД, такими как MySQL, Postgress и др.
  • Изменение данных

Настройки производительности

  • Оптимизация производительности
  • Настройка параметров СУБД Oracle
  • Планирование нагрузки и емкости
  • Решение задач, связанных с логической структурой СУБД Oracle
  • Создание индексов
  • Оптимизация работы запросов
  • Чтение планов выполнения запросов
  • Анализ отчетов производительности СУБД
  • Table Partitioning

Безопасность

  • Разграничение прав доступа и настройка политик безопасности
  • Шифрование данных и управление доступом
  • Advanced Security
  • Key Vault
  • Audit vault и Database Firewall
  • Oracle Label Security
  • Oracle RAS(Real Application Security)
  • Oracle Data Safe
  • Oracle Data Masking

Управление

  • Регулярные встречи и обзор текущего состояния Систем
  • Сертифицированные инженеры
  • Выделенный технический аккаунт-менеджер
  • Доступ в сервис деск Исполнителя

Как это работает: департамент технического менеджмента

Рубрику о жизни компании продолжает руководитель департамента технического менеджмента Григорий Зеф.

Григорий, Как Вы можете описать задачи Вашего департамента “в двух словах”?

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

Вот как видят нас наши клиенты:

Какими технологиями владеют сотрудники департамента?

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

Кроме этого, необходимы знания в сфере методологии управления (ITIL) для полноценного покрытия всех процессов сопровождения.

Как строится работа в департаменте?

Работа строится на трех составляющих, описанных в инструкции: тактической (координация работ), аналитической (анализ статистики и Problem Management), стратегической (отслеживание ключевых показателей систем клиента). Для удобства контроля настроены вспомогательные инструменты и оповещения в тикетной системе (Jira), отчетной системе (BI), шаблоны в системе документирования (Confluence).

Какими проектами и решениями Вы особенно гордитесь?

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

Как Вы видите отдел через 5 лет?

Департамент, в полномочия которого будут входить не только техническое управление определенными направлениями/технологиями клиента, но и погружение клиента в современный мир ИТ. Логичным продолжением технического менеджмента станет управление и направление ИТ службы клиента и в максимальном приближении его замена.

Как попасть в Вашу команду?

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

DBI в лицах: Камилла Литвински

Мы продолжаем рубрику DBI в лицах и знакомство с нашими сотрудниками! Сегодня пообщались с Камиллой Литвински, поговорили о работе в департаменте аналитики, развитии на профессиональном пути и литературе, которая помогает ей совершенствовать навыки в IT.

— Камилла, как правильно называется твоя должность? 

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

Расскажи о своих обязанностях в DBI.

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

Что самое главное для тебя в работе?

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

А что помогает тебе развиваться в профессиональном плане?

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

Кем ты видишь себя через 5 лет?

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

— Камилла, а чем ты любишь заниматься вне работы?

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

— Порекомендуй книги/вебинары, которые тебе больше всего помогли на твоем профессиональном пути.

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