Нека си признаем, всички копнеем за проекти на зелено. Има ли някой, който не иска празен лист за проект, шанс да започне нещо толкова чисто, толкова обмислено, самият код се чете като парче от Стружките вечери на поезията, архитектурната диаграма, достойна за място във вашия стената на спалнята точно до плаката на Lamborghini (или любимата boyband)?!

Проблемите ще започнат да се трупат доста бързо, доста скоро след поставянето на първия градивен елемент, ако не зададете някои основни правила. Ето моите 5 правила за перфектен контрол на стартирането на проекта:

Сигурност! Сигурност! Сигурност!

Ще го кажа отново, СИГУРНОСТ! Не мога да подчертая достатъчно колко важно е това. Не изрязвайте ъглите тук. Ако изплетете защитните си парапети от самото начало, ще бъде много по-лесно еволюцията на проекта да се случи в рамките на ограничаването на тези мерки за сигурност. Изключително по-трудно е по-късно да се преработи и да се проследят всички свободни краища, за да можете да подсилите проекта си. Ето някои от най-честите грешки, допускани при нови проекти:

Всички инженери работят от вкъщи и имат динамични IP адреси, така че нека просто оставим базата данни публична и отворена към 0.0.0.0/0, за да могат лесно да се свързват с нея и бързо да доставят функции. Не се притеснявайте, ние ще го защитим с много сложна парола.

Познай какво?! Трябва да се тревожите. Вашата „много сложна“ парола е буквално последната линия на защита и, честно казано, тя е много тънка. Има много други начини да причините хаос на вашата система, ако изложите вашата база данни на света. Вашата система внезапно става много по-уязвима за социално инженерство (необходима е само една парола, за да бъде напълно активирана), DDoS атаки на вашия публичен сървър IP (облачните доставчици не са неподатливи на това, нали знаете?!), Slowloris (най-много страхотно име за кибератака) и много повече. Това е мечтаната площадка на хакерите.

Защо някой ще иска да ни напада?! Ние сме незначителен играч на пазара, тепърва започваме, нямаме врагове. Можем да си позволим да бъдем малко по-малко строги по отношение на сигурността.

Нека ви разкажа една кратка история, веднъж присъствах на фирмено събитие (комедийно импровизирано шоу), където веднага след като влязох в театъра, мой приятел, за когото е известно, че се занимава с черните изкуства (шапки), стои на входа, сканира място за слаби места точно като функцията за анализ на заплахите на Robocop и вижда театралния проектор. Изважда телефона си и с помощта на инфрачервения порт поема контрола над него за по-малко от минута. Когато го попитах защо, този път и всеки друг път, когато направи такава каскада, отговорът винаги беше един и същ: „Защото мога!“. Понякога вие/вашият проект/вашата компания ще станете мишена само защото сте се оставили уязвими. Друг пример е фиаското на магазина на телевизионния доставчик в моята родна страна. Тъй като телевизорите в магазина бяха постоянно включени и никой не си направи труда да смени ПИН-а на защитените канали, някой, уж за шутове, взе дистанционно от същия ТВ бокс от вкъщи и смени всички телевизори в магазина на „възрастни“ ” канали. Бих платил пари, за да видя външния вид на първия служител, който отвори магазина на следващата сутрин.

Мога да продължа да говоря за други проблеми като:

  • Дайте на всички права на администратор, защото вярвате, че знаят какво правят
  • Пропуснете тази проверка за разумност, защото наистина сте сигурни, че промяната ви е толкова малка, че не би могла да счупи нищо и т.н.

Въпросът е, че е по-добре да сте в безопасност, отколкото да съжалявате! Съгласете стандартните мерки за сигурност, първо ги приложете и едва след това започнете да изграждате проекта си.

Моят стандартен набор от правила обикновено включва:

  • Задължително МВнР
  • Достъп с най-малко привилегии
  • Няма широко отворени групи за сигурност
  • Политика за силна парола (18+ знака, 3-месечна ротация)
  • Без повторно използване на парола
  • Шифроване на всички данни в покой

Заредете своята кутия с инструменти

Повечето днешни компании, когато наемат нов служител, му изпращат (в дивите времена, когато правехме нещата лично, добре знам) пакет, пълен с екстри, като лаптоп, тетрадка, чаша за кафе с вдъхновяващ цитат което никога не е вдъхновявало никого, малко цветно пухкаво топче, което можете да поставите върху молива си, визитна картичка на партньор терапевт и т.н. Това представлява стандартният набор от неща, които всеки използва. И така, защо проектите да нямат това? Ако очертаете инструментите, които вашият проект ще използва, всички ще бъдат на една и съща страница и никога няма да има ненужно бърборене и сблъсък на неща. Ето няколко примера за инструменти, които трябва да дефинирате предварително:

  • Контрол на версиите: Gitlab, Github, Bitbucket и т.н. (форматиране на съобщения за ангажиране)
  • Инфраструктура като код: Cloudformation, Terraform, Pulumi и др. (заедно с точната версия)
  • Документация: GDocs, Confluence, Readme и др. (дефинирайте шаблон)
  • Проследяване на проблеми: JIRA, Trello, Redmine и др. (дефиниция за готово, дефиниция за готово)
  • Диаграми: Visio, Draw.io и др.

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

Rise Sir Production-Server-Work-a-Lot

Ако можете да преброите времето, което ИТ хората са отделили най-много по време на кариерата си, мисля, че ще откриете, че почти всички от тях имат един елемент от най-висок ранг: именуване на неща. Аз съм от хората, които назовават всичко около себе си. Моят лаптоп за игри се нарича „Legionnaire“ (това е Lenovo Legion, аха), а работният ми е „The Thinker“ (очевидно Lenovo ThinkPad). Но също така всяка дива птица навън се казва Бим (не ме питайте защо), всяко ново куче е Джаки, а името на колата ми е Хю (обзалагам се, че няма да познаете марката :D ). Това ми дава чувство за собственост, начин да комуникирам по-ефективно, когато трябва да спомена нещо. Същото важи и за DevOps проектите. Силната конвенция за именуване е като GPS през инфраструктурен лабиринт. Важно е да го настроите от самото начало. Може да бъде, както ви харесва, можем да спорим за плюсовете и минусите на всеки шаблон за конвенция за именуване, но в крайна сметка става въпрос за лични предпочитания. Но ИМАТЕ ГО и се придържайте към него. Никога не се отклонявайте от него.

Начинът, по който аз лично мисля за именуване на неща в моя свят на DevOps, е следният:

Ако направя експортиране на името на всяко едно нещо, което съм създал в моя проект (напр. AWS ресурси и услуги), искам да намеря това, от което се нуждая, чрез процес на елиминиране или изрязване на части от списъка.

Моята конвенция за именуване за ресурси на AWS например е:

<environment>-<region>-<product>-<name/uid>-<type>

По този начин мога някак да „пробивам“ ресурсите си, докато стигна до нивото, от което се нуждая. В една „итерация“ мога да видя всичко, което изпълнявам в PRD (производство). Мога да виждам всичко, което е необходимо за изпълнение на определена част от моя проект, било то продукт или услуга, или друго, което съм организирал проекта си. Не казвам, че това е конвенцията за именуване, която управлява всички тях, но работи за мен и моите проекти.

Вие сте ИТ

Как става така, че когато повечето от вас публикуват снимка във вашата емисия в Instagram, можете да измислите поне 10 хаштага, които да добавите към нея, но ако ви помоля да измислите етикети за конкретна база данни или екземпляр на сървъра, засядате на нещо извън името (за което вече се разбрахме :) ), или може би още едно или две?

Няма човек, когото познавам, който да не е израснал, играейки най-универсалната вечна игра „Tag“, която разбива езиковата бариера. Е, предполагам, че можете да мислите за това като за „Етикет 2.0, цифрово издание“. В Tag 2.0, когато докоснете нещо, то не е само „ТО“, то също е „Това“ и „Това“ и може би „Също това“. Етикетите във вашата инфраструктура са като метаданни. Те казват толкова много с толкова малко думи и съчетано със силната конвенция за именуване, това е съвпадение на небето. Някои тагове, които да обмислите да добавите към ВСИЧКИ свои ресурси, са:

  • CostCentre: Core, Dev, QA, PRD, API, Web и т.н. Зависете от вас как искате да организирате своя преглед на таксуването.
  • Среда: Dev, Acc, Prd. и т.н… Въпреки че това също е в името, програмното запитване за ресурси от определена среда е много по-лесно (да се чете „по-добре“) с таг, отколкото с регулярен израз, анализиращ низа на името.
  • Услуга:API, WEB, ADMIN, CORE, MOBILE и т.н. Може да бъде всяко логическо разделяне на услугите, които имате във вашия проект. Може би дори всяка микроуслуга, ако използвате тази архитектура.
  • Автоматично генерирано: Вярно/Невярно. Ако даден ресурс има този етикет, зададен на true и вие направите ръчна промяна в него, вие заслужавате всички последствия, които ще последват след следващото издание на вашия IaC.
  • Хранилище:ако използвате множество хранилища, за да организирате кода си, името или дори целият URL адрес на репото, съхранен в този маркер, може да има същия ефект като използването на измама на „Къде е Уолдо“ за незабавно намиране него.

Честито малко дърво

Не на последно място в тази настройка за контрол на стартирането е дървовидната структура на папките на хранилището. Това е особено важно, ако използвате стратегия за множество хранилища. Определянето къде са нещата във вашето хранилище е почти същото като организирането на къщата ви. Ако искате да сготвите яйца, отивате в кухнята; ако искате да заведете кучето си на почивка в гърнето, заведете го/я в градината. Същото трябва да е и с кода на вашето хранилище. Ако искате да направите определена промяна, трябва незабавно да знаете къде да я направите. Това варира значително в зависимост от контекста на проекта и наистина няма грешен начин да го направите, стига за всички да е ясно какво къде отива. Има хранилища на шаблони за почти всеки проект Hello World и можете също да използвате инструменти като cookie-cutter.

Заключение

Знам, че всички сме нетърпеливи да изцапаме ръцете си в нови проекти, особено проекти на зелено, но отделянето на време за дефиниране на тези няколко неща предварително може да ви спести безброй часове от времето ви и може би няколко косъмчета на главата ви в бъдеще. Вече живеем в достатъчно хаотичен свят, какъвто е, особено в света на ИТ, така че добавянето на тази част от структурата и стандартизацията към малкото малко парче от него няма да навреди, но може да накара някой разработчик или DevOps да се усмихне някъде само за миг и небето ще се отвори и слънчев лъч ще блести върху клавиатурата и от нея ще излезе шедьовър на софтуера. Софтуер, който просто може да стане докторска степен. изследователска тема на бъдещ ИТ историк. Не е ли това, към което всички се стремим?!