Публичная техническая политика

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

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

Разработка безопасного ПО

В ГК Теком мы следуем принципам, подходам, практикам и национальным стандартам Разработки Безопасного ПО, рассмотренным ниже.

Основные принципы безопасности при разработке ПО

1. **Security by Design** — безопасность закладывается на каждом этапе разработки, а не добавляется после.
Принципы безопасности, заложенные на этапе проектирования архитектуры, являются основой безопасного ПО и не могут быть добавлены в полном объёме после разработки.
2. **Zero Trust** — ни один участник взаимодействия — ни внешний, ни внутренний, ни пользователь, ни система — не считается доверенным по умолчанию.
Каждый участник взаимодействия проходит обязательную процедуру аутентификации и авторизации с выделенной персональной/технологической учётной записью.
3. **Принцип наименьших привилегий** — каждый компонент, сервис и пользователь получают ровно тот уровень доступа, который необходим для достижения поставленной цели и решения задачи.
4. **Минимизация поверхности атаки** — отключается и удаляется всё, что не используется.
Зависимости, инфраструктурные компоненты регулярно проходят аудит и обновляются.
5. **Эшелонированная защита** — реализуются независимые уровни защиты так, что отказ одного уровня не отменяет остальных.
Используются уровни защиты: физический и сетевой, защита рабочих станций и серверов, уровень защиты приложений и их данных, а также организационно-административный на основе политик, регламентов и процедур.

Следование стандартам

В ГК Теком мы активно следуем национальным стандартам разработки безопасного ПО:

— ГОСТ Р 56 939−2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования»
— ГОСТ Р 71 207−2024 «Защита информации. Разработка безопасного программного обеспечения. Статический анализ программного обеспечения. Общие требования»
— ГОСТ Р 59 548−2022 «Защита информации. Регистрация событий безопасности. Требования к регистрируемой информации»

Для следования ГОСТ Р 56 939−2024 выполняем следующие пункты:

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

Для следования ГОСТ Р 71 207−2024 используем общепринятный инструментарий для проведения статического анализа ПО, удовлетворяющий общим требованиям к статическим анализаторам и количеству ложноположительных и ложноотрицательных срабатываний.

Для следования ГОСТ Р 59 548−2022 проводим регистрацию событий безопасности, учитывая требования ГОСТ к регистрируемой информации.
Постоянно работаем над улучшением и расширением как количества регистрируемых событий информационной безопасности, так и объёма информации в регистрируемых событиях.

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

Общие инженерные принципы и ценности

В ГК Теком мы придерживаемся следующих инженерных принципов и ценностей:

— **Простота** — мы выбираем наименее сложные и при этом надёжные решения
— **Автоматизация** — мы не делаем вручную то, что можно автоматизировать и переиспользовать
— **Наблюдаемость и измеримость** — наши решения понятны и измеримы в эксплуатации, сопровождении и обслуживании
— **Безопасность по умолчанию** — механизмы защиты и безопасности встроены в каждый этап PDLC и SDLC (Product and Software Development Lifecycle (s))
— **Отказоустойчивость и надёжность** — мы проектируем и разрабатываем системы, ожидая сбои и реализуя автоматические механизмы восстановления с минимальным внешним вмешательством, обеспечивая высокую доступность и надёжность поставляемых решений
— **Масштабируемость и производительность** — наши системы разрабатываются эластичными, чтобы динамически подстраиваться под рабочую нагрузку, поддерживая требуемую производительность
— **Непрерывное улучшение** — регулярно пересматриваем процессы и устраняем технический долг
— **Прозрачность и ответственность** — каждый инженер отвечает за результаты своей работы от идеи до поставки в производственную среду заказчика

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

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

Проектирование и архитектура

Принципы проектирования архитектуры ПО определяют «скелет» системы, легкость или сложность её расширения и потенциал развития.
Инженеры ГК Теком на постоянной основе при проектировании придерживаются следующих принципов:

— **Абстракция и инкапсуляция** — системы проектируются, скрывая сложность и детали реализации за простыми и стабильными интерфейсами, повышая безопасность системы и обеспечивая возможность изменений без влияния на пользователей.
— **Слабая связность** — модули и сервисы, составляющие систему, разрабатываются слабо связанными, без внутреннего состояния для обеспечения независимости и взаимозаменяемости компонент.
Выходящая из строя часть системы имеет минимальное влияние на оставшуюся работоспособную часть и может быть быстро заменена.
— **Проектирование через контракты** — взаимодействие компонент системы строится на явных контрактах (API-схемы, протоколы), обеспечивающих возможность строгой валидации входных/выходных данных и гибкую интеграцию со смежными системами.
— **Отказоустойчивость и graceful degradation** — решения ГК Теком реализуют отказоустойчивую архитектуру, что в случае выхода из строя части сервисов, система продолжает работать и обслуживать пользователей. В зависимости от количества отказов оборудования обслуживание может происходить в ограниченном режиме.
— **Горизонтальная масштабируемость** — используемая распределённая сервисная и микросервисная архитектура позволяет наращивать производительность
добавлением экземпляров сервисов без необходимости увеличения вычислительной мощности используемого аппаратного обеспечения (hardware).
— **Идемпотентность** — распределённые системы часто выполняют повторные операции и обработку.
Решения разрабатываются так, что повторное выполнение и обработка не приводят к побочным эффектам и нарушению целостности данных.
— **Конфигурируемость** — система обеспечивает гибкую настройку за счёт гранулированной конфигурации как на этапе развертывания, так и в процессе эксплуатации.
Большая часть конфигурации поддерживает динамическое обновление в процессе работы системы без необходимости перезапуска её компонент.
— **Наблюдаемость** — на этапе проектирования закладывается возможность включения детального логгирования, дополнительных метрик и добавления трассировочной информации для обеспечения измеримости характеристик системы, повышения скорости реакции на сбои и восстановления работоспособности.
Трассировочная информация отражает внешнее воздействие на систему, связывается с уникальным идентификатором события, по которому можно легко отследить весь процесс обработки в логах и аудите.
— **Масштабируемость** — при проектировании сервисных компонентов предпочтение отдаётся stateless-подходу с использованием выделенных хранилищ данных с собственной процедурой аутентификации, все компоненты систем реализуют слабую связность на основе асинхронного обмена сообщениями через платформы обмена сообщениями, обеспечивая гибкое развертывание компонент и независимую обработку данных. Используется контейнеризация для обеспечения развертывания под требования нагрузки.
— **Обратная совместимость** — при разработке новых версий решений и их отдельных компонентов учитывается требование обратной совместимости — как между компонентами системы, так и с более ранними версиями одного и того же компонента. Таким образом обеспечивается возможность инкрементального обновления без полной остановки и увеличения времени бесперебойной работы системы.
Обратная совместимость может нарушаться при обновлении major версии ПО. Например, при обновлении версии с 5. х на 6. х и аналогичных.

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

Распределённые системы и согласованность данных

При асинхронном взаимодействии сервисов в продуктах ГК Теком обеспечивается надёжная доставка событий и целостность данных.
Для сценариев, где изменение состояния в базе данных должно быть атомарно связано с публикацией событий,
применяем архитектурный шаблон Transaction Outbox, когда событие сохраняется в той же транзакции, что и бизнес-данные, и асинхронно доставляется подписчикам.

Transaction Outbox используется, когда потеря события после успешной записи в БД недопустима и система построена на event-driven архитектуре.

При этом применяются и более простые подходы:

— для простых синхронных интеграций достаточно прямых API-вызовов;
— для длинных бизнес-процессов используется Saga с компенсирующими операциями;
— для трансляции изменений данных без изменения исходного кода — Change Data Capture подход.

Дополнительно во всех асинхронных сценариях реализуются:

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

**В продуктах ГК Теком используются и альтернативные подходы, а также подходы, дополняющие Transaction Outbox:**

Качество и практики разработки

Качество предоставляемых решений зависит и от инженерных практик, применяемых в процессе реализации спроектированной архитектуры.
Инженеры ГК Теком при решении каждой задачи придерживаются общепринятых методик и практик:

— **SOLID** — акроним, обозначающий базовый набор принципов проектирования и программирования
— Single Responsibility Principle — принцип единственной ответственности для каждого модуля и компонента ПО с простыми и понятными взаимосвязями ускоряет разработку и поддержку продуктов
— Open-Сlosed Principle — используя принцип открытости для расширения и закрытости для изменений, безопасно расширяем существующий функционал, снижая риски регрессии
— Liskov Substitution Principle — применяем принцип подстановки типов, позволяющий безопасно развивать согласованные контракты между компонентами
— Interface Segregation Principle — разделяем интерфейсы компонент для безопасного и целевого использования
— Dependency Inversion Principle — инверсия зависимостей позволяет гибко управлять взаимосвязями
— Composition over Inheritance — предпочтение композиции над наследованием позволяет избежать сложностей и уменьшить накладные расходы при развитии и расширении функционала
— **KISS** — Keep it Simple, Stupid — предпочтение отдаётся наиболее простому из решений, удовлетворяющих требованиям.
Мы не усложняем требования, а реализуем непосредственно то, что нужно нашим клиентам и партнёрам.
— **YAGNI** — You Ain’t Gonna Need It — мы не делаем что-то только по причине, что это может понадобиться в будущем.
Мы конкретизируем, уточняем требования и реализуем именно то, что нужно.
— **DRY и SSO** — Don’t Repeat Yourself и Single Source of Trust. Мы придерживаемся единого источника истины на основе подходов GitOps/DocOps.
Описание требований, пользовательских сценариев, бизнес-логики, код, конфигурация всегда находятся в одном месте с контролем изменений.
Дублирование источников повышает риск рассинхронизации данных и возникновения проблем.
— Принцип наименьшего удивления (Principle of Least Astonishment) — используем общепринятые отраслевые подходы, названия, спецификации, чтобы инженеры, специалисты по маркетингу и продажам говорили на одном языке, понимали друг друга и своих коллег из компаний клиентов и партнёров.
— **Fail Fast, Recover Quickly** — мы не пытаемся угадывать и делать единую конфигурацию своих решений под всех заказчиков.
Инженеры рассчитывают требуемые характеристики с учётом специфики каждого клиента, а если что-то оказывается упущенным, то система формирует диагностическую информацию в виде понятных логов, трейсов и метрик.

Качество обеспечивается не только практиками и принципами, но и процессами, накладываемыми на них:

1. **Единые Code Conventions для кодирования**. В процессе разработки команды придерживаются единых «Соглашений по написанию кода»
на основе общепринятых правил и норм разработки ПО по каждому стеку (Java/Kotlin, C/C++, JavaScript/TypeScript, C#, Python), включая дополнительные правила и соглашения, выработанные внутри ГК Теком.
Code Conventions регулярно пересматриваются и поддерживаются в актуальном состоянии главными и ведущими инженерами компании.

2. **Обязательные Code Review**. Инспекции кода на всех уровнях согласно единым Code Conventions — неотъемлемая составляющая ежедневной работы как инструмент поиска потенциальных проблем, так и обмена знаниями от опытных коллег к специалистам начального и среднего уровней.
Экспертиза исходного кода подразумевает не только инспекции кода, но и конфигурации, скриптов автоматизации, а также пользовательских сценариев, сценариев тестирования и документации согласно подходам GitOps/DocOps.

3. **Definitions of Done** — используем ясные и конкретные критерии готовности задачи и реализации функциональных и нефункциональных требований:
— аналитика выполнена и сценарии использования описаны
— проектирование проведено и архитектура утверждена
— код разработан, включая функциональные и интеграционные тесты
— ревью пройдено успешно как специалистами, так и автоматизированным инструментарием
— pipelines автоматизированного тестирования и сканирования SAST, Secrets Scan, SCA, DAST — имеют зеленый статус
— документация, инструкции по миграции, release notes обновлены и выложены для команд тестирования и сопровождения
— необходимые метрики, трассировочная информация добавлены и мониторинг под них настроен
— при реализации нефункциональных требований проводится соответствующее дополнительное тестирование: нагрузочное, тестирование производительности, безопасности и другие

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

4. **Автоматизированное тестирование** — придерживаемся требования покрытия не менее 80% функциональных и нефункциональных требований авто-тестами
на всех уровнях: unit → integration → contracts (api) → end—to—end (e2e). Автоматизированное тестирование является обязательной частью Definitions of Done, состоящее из следующих частей:
— API-тесты как обязательный этап проверки соблюдения контрактов и поведения API
— е2е (end—to—end) тесты как обязательный этап проверки корректности реализации пользовательских сценариев через UI веб-приложения в целевом браузере
— smoke-тесты как быстрый контур проверки работоспособности существующих критичных сценариев после реализации новой функциональности или изменений в существующей
— интеграционные тесты как обязательный этап проверки взаимодействия ПО с инфраструктурными компонентами, внешними сервисами и внутренними модулями друг с другом
— хаос-инженерия и нагрузочное тестирование используются для проверки устойчивости ПО не только в теории,
но и контролируемым внесением сбоев и пиковых нагрузок на систему и её отдельные компоненты.

5. **Непрерывная интеграция и развертывание** — автоматизированные конвейеры статического анализа кода (SAST, Secrets Scan), сборки артефактов, прогона авто-тестов,
сканирования собранных артефактов (SCA) для каждого изменения, вносимого в кодовую базу с дальнейшим автоматическим развёртыванием ПО
с изменениями в тестовое окружение для ручного и автоматизированного тестирования
— обеспечивают быстрое обнаружение проблем
— снижают стоимость исправления ошибок на более поздних этапах
— делают процесс разработки более предсказуемым и управляемым
— автоматизируют процесс интеграции и развертывания, в том числе используемый в производственной среде заказчиков

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

6. **Документирование на каждом этапе** — используем подход к управлению документацией как инженерным артефактом и частью жизненного цикла продукта (Documentation as Code and DocOps).
— Документация — это не «побочный артефакт» разработки, а управляемый, автоматизированный инженерный актив.
— Применяем к разработке документации все практики и подходы как к коду продукта: версионирование, ревью, автоматизация сборки и тестирование.
— Документация включает не только User/Admin Guides, но и документацию архитектуры, конфигурации, API, Troubleshooting Guide и многое другое.
— Жизненный цикл документации совпадает с жизненным циклом ПО. Изменения в документацию вносятся вместе с изменениями кода продукта.

Информационная безопасность продуктов ГК Теком

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

В данном разделе рассмотрим кратко способы и подходы, используемые в продуктах ГК Теком, для обеспечения безопасной работы пользователей.

Аутентификация и авторизация

1. Явная верификация запросов. Каждый запрос к ПО проходит процедуру аутентификации и авторизации.
2. Принцип наименьших привилегий. Пользователи ПО получают минимально необходимый доступ для выполнения только требуемых действий на основе гранулированной RBAC-модели.
3. Поддержка и использование JWT-токенов с валидацией подписи, интроспекцией и возможностью отзыва токенов.
4. Использование API Gateway как единой точки входа и управляющего слоя между внешними клиентами и внутренней инфраструктурой сервисов.
5. Поддержка динамической авторизации на основе гибкой гранулированной RBAC-модели с назначением прав/разрешений как непосредственно пользователю, так и группе пользователей.
6. Поддержка Edge-авторизации. На входе происходит проверка базовых глобальных прав пользователя, а в самом сервисе проверяются локальные права на доступ к конкретным устройствам.
7. Поддержка как локальных учётных записей пользователей, так и учётных записей с аутентификацией по LDAP.

Валидация входных данных и обработка ошибок

1. Все входные данные проходят строгую валидацию на соответствие ожидаемой схеме данных и требуемых/опциональных полей.
2. Все запросы с некорректными данными отклоняются с единой структурой ответа и соответствующим кодом. Полный список с описанием всех кодов ошибок приведён в документации к ПО.
3. Защита от SQL-инъекций и XSS-атак.
4. Использование TLS 1.3 для всех внешних запросов.

Парольные политики

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

Аудит и логгирование ошибок

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

Взаимодействие компонент

1. Модули ПО не взаимодействуют друг с другом напрямую.
2. Взаимодействие происходит только с инфраструктурными (3rdParty) компонентами как БД (SQL, NoSQL), cache servers, brokers, платформы обмена сообщениями.
3. Встроенные учётные записи инфраструктурных (3rdParty) компонент, используемые по умолчанию, выключены и заменены на уникальные выделенные учётные записи для работы с системой.
4. Со всеми компонентами взаимодействие происходит через встроенные поддерживаемые механизмы аутентификации и авторизации, используя уникальные выделенные УЗ для доступа к каждому компоненту, обеспечивая изоляцию компонент и их безопасное взаимодействие.

Развёртывание и эксплуатация

Надёжность и предсказуемость решений ГК Теком обеспечиваются не только качеством исходного кода, но и зрелыми процессами развёртывания и эксплуатации.
Мы придерживаемся практик DevOps и Site Reliability Engineering (SRE), чтобы гарантировать высокую доступность,
безопасность и управляемость систем на всём протяжении их жизненного цикла в производственной среде заказчика.

В своей работе инженеры ГК Теком придерживаются следующих подходов к развёртыванию ПО.

**Подходы к развёртыванию**

1. **Infrastructure as Code (IaC)** — рассматриваем инфраструктуру как код. Процессы развёртывания инфраструктурных компонент полностью автоматизированы и версионированы, что исключает «ручное» конфигурирование серверов и гарантирует идентичность окружений (тестовое, предпроизводственное, производственное).
2. **GitOps** — система конфигураций и манифестов развёртывания хранится в Git, который выступает единственным источником истины (Single Source of Truth). Любые изменения в инфраструктуре проходят через процесс ревью (Pull/Merge Requests) и применяются специализированными инструментами.
3. **Контейнеризация и оркестрация** — все компоненты систем поставляются в виде неизменяемых (immutable) контейнерных образов. Для оркестрации используются платформы управления контейнерами (например, k3s/k8s), что обеспечивает горизонтальную масштабируемость, самовосстановление и независимое управление жизненным циклом каждого микросервиса.
4. **Zero Downtime Deployments** — обновление компонент системы в производственной среде заказчика происходит без прекращения обслуживания пользователей. Применяются стратегии rolling update, а также blue/green и canary (канареечные) релизы для безопасного и поэтапного внедрения новых версий.
5. **Автоматический Rollback** — в случае неудачного развёртывания или падения ключевых метрик «здоровья» ПО после развёртывания новой версии, происходит откат к предыдущей стабильной версии в рамках используемой автоматизации и триггеров.

**Эксплуатация и наблюдаемость (Observability)**

В основе эксплуатации систем ГК Теком лежит проактивный мониторинг и полная наблюдаемость, заложенная ещё на этапе проектирования архитектуры:

* **Три кита наблюдаемости** — продукты ГК Теком в обязательном порядке собирают и предоставляют три вида телеметрии:
* _Метрики_: время ответа, утилизация ресурсов, количество ошибок, бизнес-показатели.
* _Логи_: детализированные записи о событиях и ошибках, структурированные для удобного поиска и фильтрации.
* _Трассировочная информация_: пути прохождения запросов через все модули/сервисы для локализации «узких мест» и причин деградации производительности.
* **SLI, SLO, SLA** — мы следуем практике определения индикаторов и целей качества обслуживания. Для критичных бизнес-сценариев рассчитываются метрики доступности и быстродействия, на основе которых формируются обязательства перед заказчиками.
* **Проактивный алертинг** — система самомониторинга (поставляемая вместе с продуктами ГК Теком) настроена на раннее предупреждение инцидентов.
Алерты срабатывают до того, как проблема затронет пользователей, позволяя дежурным инженерам реагировать превентивно.
Используем подход «Fast alerting, actionable metrics» — стремимся минимизировать нерелевантные и дублирующие уведомления. Точечно настроенные оповещения содержат конкретный контекст для быстрого принятия решения.
* **Self-monitoring** — поставляемое решение включает в себя встроенную систему самомониторинга, позволяющую администраторам и службам сопровождения заказчика самостоятельно отслеживать состояние системы, производить поиск причин и устранять инциденты.

**Управление конфигурацией и секретами**

1. Конфигурация продуктов ГК Теком разделена на настройку окружения, бизнес-логику и параметры инфраструктурных компонент.
2. При этом в ПО используется динамическое обновление значительной части конфигурации без необходимости перезапуска сервисов (hot reload).
3. **Безопасность секретов** — для управления ключами, паролями, токенами и сертификатами используются специализированные системы управления секретами (Secrets Management).
Секреты не передаются в открытом виде через переменные окружения или исходный код.

Политика в области открытого ПО

Коммерческие решения ГК Теком разрабатываются в том числе с использованием компонент с открытым исходным кодом по open-source лицензиям.
Перед использованием open-source компоненты проходят тщательную верификацию используемых лицензий.
Выбираются только те компоненты, лицензии которых не накладывают ограничений на клиентов и партнёров ГК Теком.

Кроме open-source в продуктах ГК Теком используется и коммерческое программное обеспечение, выбираемое исключительно из ["Реестра российского ПО"](https://reestr.digital.gov.ru)

Техническая коммуникация и поддержка

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

Открытая коммуникация и поддержка инженеров ГК Теком как в разработке ПО, так и в процессе эксплуатации обеспечивают
— быстрое решение технических проблем
— быстрое восстановление работоспособности ПО
— поиск первопричин с последующим устранением без повторных сбоев

В ГК Теком выделены организованные площадки как для открытого внутреннего взаимодействия инженеров для обмена знаниями и опытом, так и для взаимодействия с представителями заказчиков, получения обратной связи и её быстрой квалифицированной проработки.

Каждый инженер может воспользоваться следующими площадками технической коммуникации:
— организовать Tech Talk и Master Class, где презентовать на практике выработанные решения и их применение
— опубликовать технический информационный пост в Tech News Channel
— перед непосредственной реализацией инженеры получают консультации в Tech Professional Chats, а также запрашивают архитектурное и техническое ревью предлагаемых решений по выбранному стеку и технологиям.

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

Таким образом обеспечивается непрерывное техническое и профессиональное совершенствование инженеров ГК Теком.