#infrastructure #sre #devops #platform
Адитья Чоудхри [adityachowdhry.com]
Начальные люди, их привычки и код имеют доминирующее влияние на то, что в конечном итоге оказывается для стартапа, и это тоже в течение значительного количества времени.
Стартапы на начальном этапе вынуждены выпускать продукты и новые функции как можно скорее, что, в свою очередь, влияет на общее качество технологий. В отличие от этого агрессивного внимания к качеству, это может повлиять на ваш стартап-бизнес.
По мере роста вашего стартапа соответствующим образом развиваются и технологии. Рефакторинг продолжается, и его невозможно избежать, так как технологиям необходимо адаптироваться к изменениям, через которые проходит ваш стартап.
Преждевременная оптимизация может принести больше вреда, чем пользы напр. разбиение монолита на микросервисы.
Эти изменения неизбежны и обычно требуют много времени и усилий. В этом процессе всегда присутствует некоторая неуверенность и неуверенность. В этом посте представлены некоторые ключевые выводы, которые могут помочь в сокращении временных затрат и повышении уверенности в отношении рефакторинга с точки зрения инфраструктуры.
Это некоторые из моих ключевых уроков
1. Соглашение важнее конфигурации
Имейте соглашение, когда вы называете свои ресурсы. Здесь ресурсом может быть что угодно, например проекты, облачные экземпляры, DNS, базы данных или что угодно.
Это применяет единообразное именование во всей вашей инфраструктуре, что позволяет программно выполнять действия и упрощает управление.
2. Метаданные
Каждый раз, когда вы предоставляете что-то новое, возьмите за привычку добавлять к нему некоторые метаданные. Это также можно автоматизировать, но сначала вы можете создать привычку добавлять его вручную.
Облачные провайдеры (AWS / GCP / Azure и т. Д.) Предоставляют возможность тегов, которые вы можете применять к различным ресурсам. Ex создание Redis? Метаданные могут быть: тип: Redis, версия: 5.0.3, команда: ABC
Это удобно, когда вам нужно идентифицировать или классифицировать ваши ресурсы.
Сколько Redis работает в моей команде? Сколько баз данных мы используем? Какие версии Postgres мы используем в продакшене?
На подобные запросы можно легко ответить, если у нас есть метаданные.
3. Инвентарь
Храните данные обо всем, что работает, это помогает в аудите и формирует основу матрицы зависимостей, которая может легко усложняться по мере роста компании. Это как-то зависит и от предыдущего пункта.
4. Сеть
Дизайн сети важен, и при проектировании сети вашей инфраструктуры необходимо соблюдать основные правила гигиены и меры предосторожности. Это может быть так просто, как
- Разделение публичных и частных подсетей
- Разделение сред разработки
- Назначение доступа, открытие портов, внесение IP-адресов в белый список - здесь также должна быть какая-то форма отслеживания. Это может стать действительно беспорядочным в мгновение ока.
Нетворкинг может стать большой болью и препятствием для роста, если не делать этого с осторожностью. Сложность возрастает с увеличением количества инженеров и масштаба.
5. Развертывание
Развертывание - это то, что очень широко используется в любой технологической компании. Развертывание в один клик и откат - две функции, которые, на мой взгляд, должны появиться как можно скорее.
Это помогает свести к минимуму ошибки и время простоя, а также повысить эффективность и скорость работы разработчиков.
6. Структурированное ведение журнала
Ведение журнала играет очень важную роль и используется для различных целей, таких как обнаружение ошибок, получение показателей или отслеживание работоспособности системы. На ранних этапах многие инженеры не обращают внимания на то, что и как регистрируются данные. Хорошая платформа для ведения журналов дает разработчикам уверенность в необходимости рефакторинга.
Что регистрировать. Регистрируйте только отслеживаемые и полезные вещи. Полезность субъективна и зависит от вашего варианта использования. Основная проблема заключается в том, что слишком много шума нарушает цель лесозаготовки.
Формат журнала. Соблюдайте форматирование журналов. Это может помочь в сопоставлении показателей и легко отслеживать вещи.
7. Мониторинг, показатели и оповещения
Всегда должны присутствовать базовые метрики, которые определяют вашу нормальную работу инфраструктуры. Это дает обзор того, как все работает, и предупреждает разработчиков, когда что-то идет не так. Их также можно использовать для сравнительного анализа.
Система предупреждений может быть такой же простой, как отправка электронного письма или сообщения Slack. Эффективная система оповещения может предотвратить или значительно сократить время простоя. Основные показатели здоровья могут быть:
- Системные показатели, такие как ЦП, память, средняя загрузка, дисковое пространство и т. Д.
- Конкретные показатели для таких компонентов, как кеш, базы данных и т. Д.
- Метрики уровня обслуживания - время отклика API, пропускная способность, Apdex и т. Д.
В этом посте освещаются только те моменты, на которых нужно сосредоточиться на ранней стадии стартапа. Сложность каждого пункта зависит от вашего варианта использования и стадии вашего запуска.
Будем рады видеть любые отзывы или ваши знания в разделе комментариев ниже.
Спасибо за внимание.
Подпишитесь на нас в Twitter 🐦 и Facebook 👥 и присоединитесь к нашей группе Facebook 💬 .
Чтобы присоединиться к нашему сообществу Slack 🗣️ и читать наши еженедельные темы о Фавнах 🗞️, нажмите здесь⬇
