Как не потерять контроль над своим ИТ-продуктом?

Можешь ли ты себе ответить на вопрос: на кого зарегистрирован кабинет маркетолога; какой логин к эквайрингу; где хостинг сайта/сервиса?

Как не потерять контроль над своим ИТ-продуктом?

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

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

Все доступы к сервисам, инструментам, ресурсам ИТ-проекта надо отслеживать и снижать риск потери контроля над ними.

Именно поэтому я подготовил небольшой чек-лист, который позволит быстро внести свои ресурсы и удостовериться, что к ним есть полный доступ.

Ресурсы я разбил на несколько групп:

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

- Почтовый сервис. Если есть корпоративная почта, значит есть сервис корпоративной почты, с помощью которого создаются адреса, регулируется доступ к текущим. Почтовых сервисов может быть много. Например, мы одно время использовали до трёх сервисов одновременно: google, yandex, mail.

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

- Облачные сервера. Сервера используются, когда обычный хостинг уже не справляется с задачами. Надо собрать доступ к панели управления облачными серверами (например, yandex, sber, mail, google).

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

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

P.S. Отдельно проверь способы восстановления почтовых адресов, на которые зарегистрированы ваши сервисы.

Ссылка на чек-лист тут.

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

Алексей Сорокин - душит - мой личный канал про разработку, ИТ, запуск MVP, управление командой и рассказы о внутренней кухне.

FTM - канал моего агентства no-code разработки.

Softlex - канал моего агентства классической разработки.

66
1 комментарий

Да, в целом стоит иметь это ввиду. Особенно в стартапе, когда основатели иногда выходят. Залетайте к нам в комьюнити, делитесь кейсами по no-code. У нас как раз стартаперы строят продукты на но-коде https://joincofo.ru/join-us

1