Посмотрим правде в глаза, мы все стремимся к новым проектам. Есть ли кто-нибудь, кому не нужен чистый лист для проекта, шанс начать что-то настолько чистое, такое продуманное, что сам код читается как отрывок из «Вечеров поэзии Струги», архитектурная диаграмма, достойная места на вашем сайте? стена спальни рядом с плакатом Lamborghini (или любимого бойзбенда) ?!
Проблемы начнут накапливаться довольно быстро, довольно скоро после того, как будет создан первый строительный блок, если вы не установите некоторые основные правила. Вот мои 5 правил для идеального контроля запуска проекта:
Безопасность! Безопасность! Безопасность!
Я скажу еще раз, БЕЗОПАСНОСТЬ! Я не могу не подчеркнуть, насколько это важно. Не срезайте здесь углы. Если вы создадите ограждения безопасности с самого начала, развитие проекта будет намного проще в рамках этих мер безопасности. Позже провести рефакторинг и отследить все незакрепленные детали значительно сложнее, чтобы вы могли усилить свой проект. Вот некоторые из наиболее распространенных ошибок, которые допускаются при работе с новыми проектами:
Все инженеры работают из дома, и у них есть динамические IP-адреса, поэтому давайте оставим базу данных открытой для 0.0.0.0/0, чтобы они могли легко подключаться к ней и быстро поставлять функции. Не волнуйтесь, мы защитим его очень сложным паролем.
Угадай, что?! Тебе стоит волноваться. Ваш «очень сложный» пароль - это буквально последняя линия защиты, и, честно говоря, это очень тонкая линия. Есть масса других способов нанести ущерб вашей системе, если вы откроете миру свою базу данных. Ваша система внезапно становится намного более уязвимой для социальной инженерии (для полного взлома требуется всего один пароль), DDoS-атак на IP вашего публичного сервера (облачные провайдеры не застрахованы от этого, вы знаете ?!), Slowloris (самого сильного). классное название для кибератаки) и многое другое. Это детская площадка мечты хакера.
Зачем кому-то нападать на нас ?! Мы незначительный игрок на рынке, только начинающий, у нас нет врагов. Мы можем позволить себе быть немного менее строгими в отношении безопасности.
Позвольте мне рассказать вам небольшую историю, я однажды посетил корпоративное мероприятие (комедийное импровизированное шоу), где сразу после входа в театр мой друг, который, как известно, баловался черным искусством (шляпами), стоит у входа, сканирует пространство для слабых мест точно так же, как функция анализа угроз Robocop и видит проектор кинотеатра. Вытаскивает телефон и через инфракрасный порт берет на себя управление менее чем за минуту. Когда я спрашивал его, почему в тот раз, и всякий раз, когда он проделывал подобные трюки, ответ всегда был один: «Потому что я могу!». Иногда вы / ваш проект / ваша компания становитесь целью только потому, что вы оставили себя уязвимым. Другой пример - фиаско с магазином ТВ-провайдеров в моей родной стране. Поскольку телевизоры в магазине были всегда включены, и никто не удосужился сменить PIN-код на защищенных каналах, кто-то, предположительно просто для шуток, достал из дома пульт от той же ТВ-приставки и поменял все телевизоры в магазине на «взрослые». " каналы. Я бы заплатил деньги, чтобы увидеть, как будет выглядеть первый сотрудник, открывший магазин на следующее утро.
Я мог бы продолжать и говорить о других проблемах, например:
- Дайте всем права администратора, потому что вы уверены, что они знают, что делают
- Пропустите эту проверку работоспособности, потому что вы действительно уверены, что ваше изменение настолько мало, что ничего не может сломать и т. Д.
Дело в том, что лучше перестраховаться, чем сожалеть! Согласуйте стандартные меры безопасности, сначала примените их, а уже потом приступайте к созданию своего проекта.
Мой стандартный набор правил обычно включает:
- Обязательный МИД
- Наименьший доступ с привилегиями
- Нет широко открытых групп безопасности
- Политика надежных паролей (18+ символов, ротация 3 месяца)
- Нет повторного использования пароля
- Шифровать все данные в состоянии покоя
Запаситесь своим ящиком для инструментов
Большинство компаний в настоящее время, когда они получают нового сотрудника, они отправляют ему (в те далекие времена мы делали что-то лично, я правильно знаю) пакет, полный вкусностей, таких как ноутбук, блокнот, кофейная кружка с вдохновляющей цитатой. это никогда никого не вдохновляло, маленький красочный шарик, который можно повесить на карандаш, визитную карточку терапевта-партнера и т. д. Это стандартный набор вещей, который все используют. Итак, почему в проектах этого не должно быть? Если вы наметите инструменты, которые будут использовать ваш проект, все будут на одной странице, и никогда не будет ненужной болтовни и столкновений. Вот несколько примеров инструментов, которые вам следует определить заранее:
- Контроль версий: Gitlab, Github, Bitbucket и т. д. (формат сообщений фиксации)
- Инфраструктура как код: Cloudformation, Terraform, Pulumi и т. д. (вместе с точной версией)
- Документация: GDocs, Confluence, Readme и т. д. (определите шаблон)
- Отслеживание проблем: JIRA, Trello, Redmine и т. д. (определение «готово», определение «готово»).
- Диаграммы: Visio, Draw.io и т. д.
Таким образом, вы настраиваете себя на успех, так что, когда ваш проект стремительно растет и вам нужно быстро масштабироваться на людей, время адаптации сокращается до минимума, поскольку способ работы стандартизирован и задокументирован.
Поднимитесь, сэр, продакшн-сервер-много работы
Если вы можете подсчитать количество времени, которое ИТ-специалисты тратили больше всего в течение своей карьеры, я думаю, вы обнаружите, что почти у всех из них есть одна важная вещь: называние вещей. Я один из тех людей, которые называют все вокруг себя. Мой игровой ноутбук называется «Легионер» (это Lenovo Legion, да), а мой рабочий - «Мыслитель» (очевидно, Lenovo ThinkPad). Но также каждую дикую птицу на улице зовут Бим (не спрашивайте меня, почему), каждую новую собаку зовут Джеки, а мою машину зовут Хью (держу пари, вы не угадаете марку: D). Это дает мне чувство сопричастности, способ более эффективно общаться, когда мне нужно на что-то сослаться. То же самое и с проектами DevOps. Строгое соглашение об именах похоже на GPS в лабиринте инфраструктуры. Очень важно настроить его с самого начала. Это может быть как угодно, мы можем спорить о плюсах и минусах каждого шаблона соглашения об именах, но в конечном итоге дело доходит до личных предпочтений. Но ИМЕЙТЕ ЭТО и придерживайтесь этого. Никогда не отклоняйся от этого.
Я лично думаю об именовании вещей в моем мире DevOps следующим образом:
Если я выполняю экспорт имени каждой отдельной вещи, которую я создал в своем проекте (например, ресурсов и сервисов AWS), я хочу найти то, что мне нужно, путем исключения или вырезания фрагментов списка.
Мое соглашение об именах ресурсов AWS, например:
<environment>-<region>-<product>-<name/uid>-<type>
Таким образом, я могу как бы «углубляться» в свои ресурсы, пока не доберусь до нужного мне уровня. За одну «итерацию» я могу увидеть все, что у меня запущено в PRD (продакшн). Я вижу все, что нужно для выполнения определенной части моего проекта, будь то продукт или услуга, или как бы я ни организовал свой проект. Я не говорю, что это соглашение об именах, которое управляет ими всеми, но оно работает для меня и моих проектов.
Ты ЭТО
Почему, когда большинство из вас публикует фотографию в ленте Instagram, вы можете сразу придумать как минимум 10 хэштегов для добавления к ней, но если я попрошу вас придумать теги для конкретной базы данных или экземпляр сервера, вы застреваете на чем-либо помимо имени (о чем мы уже договорились :)), или, может быть, на одном или двух?
Я не знаю человека, который не вырос бы, играя в самую универсальную вечную игру «Tag», которая преодолевает языковой барьер. Что ж, я думаю, вы можете думать об этом как о «Tag 2.0, Digital Edition». В теге 2.0, когда вы касаетесь чего-либо, это не просто «ЭТО», это также «Это», «То» и, возможно, «Еще то». Теги в вашей инфраструктуре подобны метаданным. Они так много говорят, используя так мало слов, и в сочетании с строгим соглашением об именах это брак, заключенный на небесах. Вот некоторые теги, которые следует добавить ко ВСЕМ вашим ресурсам:
- CostCentre: Core, Dev, QA, PRD, API, Интернет и т. д. Как вы хотите организовать обзор биллинга - решать вам.
- Среда: Dev, Acc, Prd. и т. д. Несмотря на то, что это также присутствует в имени, программный запрос ресурсов из определенной среды намного проще (читай «лучше») с помощью тега, чем регулярное выражение, анализирующее строку имени.
- Сервис: API, WEB, ADMIN, CORE, MOBILE и т. д. Это может быть любое логическое разделение сервисов, которые у вас есть в вашем проекте. Может быть, даже каждый микросервис, если вы используете эту архитектуру.
- Создано автоматически: верно / неверно. Если для ресурса этот тег установлен в значение true, и вы вручную вносите в него изменения, вы заслуживаете всех без исключения последствий, которые последуют после следующего выпуска вашего IaC.
- Репозиторий: если вы используете несколько репозиториев для организации своего кода, имя или даже весь URL-адрес репо, хранящийся в этом теге, может иметь тот же эффект, что и использование чит-кода на «Где Уолдо» для немедленного поиска его.
Счастливое маленькое дерево
И последнее, но не менее важное в этой настройке управления запуском - древовидная структура папок репозитория. Это особенно важно, если вы используете стратегию с несколькими репозиториями. Определение того, где что находится в вашем репозитории, во многом похоже на организацию вашего дома. Если вы хотите приготовить яйца, вы идете на кухню; Если вы хотите взять свою собаку на горшок, вы должны отвести ее в сад. То же самое должно быть с кодом вашего репозитория. Если вы хотите внести определенное изменение, вы должны сразу знать, где это сделать. Это сильно различается в зависимости от контекста проекта, и на самом деле нет неправильного способа сделать это, если всем ясно, что и куда идет. Существуют репозитории шаблонов практически для любого проекта hello world, и вы также можете использовать такие инструменты, как cookie-cutter.
Заключение
Я знаю, что мы все стремимся запачкать руки в новых проектах, особенно в проектах с нуля, но если вы потратите время на то, чтобы определить эти несколько вещей заранее, это может сэкономить вам бесчисленные часы вашего времени и, возможно, несколько волосков на вашей голове в будущем. Мы уже живем в достаточно хаотичном мире, особенно в мире ИТ, поэтому добавление этой части структуры и стандартизации к ее крохотной крохотной части не причинит вреда, но может вызвать улыбку у разработчика или DevOps. на мгновение, и небо откроется, и луч солнца засияет на клавиатуре, и из нее выйдет шедевр программного обеспечения. Программное обеспечение, которое могло бы стать доктором философии. Тема исследования будущего историка информационных технологий. Разве не к этому мы все стремимся ?!
