25.08.20262 мин
В небольших командах пароли и ключи доступа часто хранятся там, где удобно в моменте: в переписке, в таблице, а иногда прямо в коде приложения. Это работает, пока команда маленькая и все друг другу доверяют - но с ростом бизнеса такой подход превращается в серьезный риск.
Пароль в коде - это пароль у всех, кто видел код
Если ключ доступа к базе данных или внешнему сервису записан прямо в коде, его получает каждый, у кого есть доступ к репозиторию - включая бывших сотрудников и подрядчиков, если доступы вовремя не отозвали. А если код случайно попадет в открытый доступ, то и все, кто угодно.
Читать →20.08.20262 мин
Технический аудит редко заказывают “просто из интереса” - обычно к этому приходят, когда что-то в работе бизнеса начинает буксовать, а причину не видно снаружи. Разберем несколько признаков, которые обычно говорят о том, что пора разобраться в технической части подробнее.
Никто не может точно сказать, как все устроено
Если ответ на вопрос “а как это работает и кто за это отвечает” звучит как “надо спросить у [конкретного человека]” - это тревожный знак. Значит, знания о системе не задокументированы и держатся на одном специалисте, а не на понятных процессах.
Читать →12.08.20261 мин
Переезд в облако - это не выбор тарифа у провайдера. Прежде чем начинать, стоит честно ответить на три вопроса: что именно переносим, зачем это нужно бизнесу и как мы поймем, что переезд завершен успешно.
Поймите, что и с чем связано
Список серверов и приложений - это только часть картины. Важно понимать, кто отвечает за каждую систему, как они связаны между собой, какие данные между ними передаются и есть ли ограничения на то, где эти данные могут храниться. Без этой карты легко упустить критичную зависимость и остановить работу нужного сервиса.
Читать →28.07.20261 мин
Многие компании создают общие внутренние инструменты для разработчиков - но набор инструментов сам по себе еще не делает такую платформу полезной. Продуктовый подход начинается с того, что команда, которая ее развивает, понимает задачи своих внутренних пользователей - разработчиков - и отвечает за то, насколько удобно им этими инструментами пользоваться.
Известно, кто ими пользуется и зачем
Команда, которая развивает платформу, знает своих основных пользователей внутри компании, понимает их типовые задачи и трудности. Решения о том, что развивать дальше, принимаются на основе реальной обратной связи от команд, а не предположений о том, что им нужно.
Читать →