Список за проверка на подготвеноста за производство

Преводот на статијата е подготвен специјално за студентите на курсот „Практики и алатки на DevOps“, кој започнува денес!

Список за проверка на подготвеноста за производство

Дали некогаш сте пуштиле нова услуга во производство? Или можеби сте биле вклучени во поддршка на такви услуги? Ако да, што ве мотивираше? Што е добро за производство, а што лошо? Како ги обучувате новите членови на тимот за изданија или одржување на постоечките услуги.

Повеќето компании на крајот ги прифаќаат пристапите на „Дивиот Запад“ кога станува збор за практиките на индустриско работење. Секој тим одлучува за своите алатки и најдобри практики преку обиди и грешки. Но, ова често влијае не само на успехот на проектите, туку и на инженерите.

Обидите и грешките создаваат средина каде што покажувањето прст и префрлањето на вината се вообичаени. Со ова однесување, станува сè потешко да се учи од грешките и да не се повторуваат повторно.

Успешни организации:

  • ја сфаќаат потребата од насоки за производство,
  • проучување на најдобрите практики,
  • започнуваат дискусии за прашањата за подготвеноста на производството кога се развиваат нови системи или компоненти,
  • обезбеди усогласеност со правилата за подготовка за производство.

Подготовката за производство вклучува процес на „преглед“. Прегледот може да биде во форма на листа за проверка или збир на прашања. Прегледите може да се направат рачно, автоматски или и двете. Наместо статични списоци со барања, можете да направите шаблони за списоци за проверка кои можат да се прилагодат на специфични потреби. На овој начин, на инженерите може да им се даде начин да наследат знаење и доволно флексибилност кога е потребно.

Кога да се провери услуга за подготвеност за производство?

Корисно е да се спроведе проверка на подготвеноста за производство не само непосредно пред пуштањето, туку и кога се пренесува на друг оперативен тим или нов вработен.

Проверете кога:

  • Пуштате нова услуга во производство.
  • Ја пренесувате работата на производствената услуга на друг тим, како што е SRE.
  • Работењето на производствената услуга го пренесувате на нови вработени.
  • Организирајте техничка поддршка.

Список за проверка на подготвеноста за производство

Пред некое време, како пример, јас објавено чек листа за тестирање на подготвеноста за производство. Иако оваа листа потекнува од клиенти на Google Cloud, таа ќе биде корисна и применлива надвор од Google Cloud.

Дизајн и развој

  • Развијте повторлив процес на градење кој не бара пристап до надворешни услуги и не зависи од неуспехот на надворешните системи.
  • За време на периодот на дизајнирање и развој, дефинирајте и поставете SLO за вашите услуги.
  • Документирајте ги очекувањата за достапноста на надворешните услуги од кои зависите.
  • Избегнувајте единствена точка на неуспех со отстранување на зависностите од еден единствен глобален ресурс. Реплицирајте го ресурсот или користете резервна копија кога ресурсот е недостапен (на пример, хард-кодирана вредност).

Управување со конфигурација

  • Статичка, мала и нетајна конфигурација може да се пренесе преку параметрите на командната линија. За сè друго, користете услуги за складирање на конфигурации.
  • Динамичната конфигурација мора да има резервни поставки во случај услугата за конфигурација да не е достапна.
  • Конфигурацијата на развојната средина не треба да биде поврзана со конфигурацијата на производството. Во спротивно, ова може да доведе до пристап од развојната средина до производствените услуги, што може да предизвика проблеми со приватноста и истекување на податоци.
  • Документирајте што може да се конфигурира динамички и опишете го резервното однесување ако системот за испорака на конфигурацијата е недостапен.

Управување со издавање

  • Детално документирајте го процесот на ослободување. Опишете како изданијата влијаат на SLO (на пример, привремено зголемување на латентноста поради промашување на кешот).
  • Документирајте изданија на канари.
  • Развијте план за преглед на ослободување на канари и, ако е можно, механизми за автоматско враќање назад.
  • Осигурајте се дека враќањето може да ги користи истите процеси како и распоредувањата.

Забележливост

  • Осигурајте се дека е собран сет на метрика потребни за SLO.
  • Осигурајте се дека можете да правите разлика помеѓу податоците на клиентот и серверот. Ова е важно за откривање на причините за дефекти.
  • Поставете предупредувања за да ги намалите трошоците за работна сила. На пример, отстранете ги предупредувањата предизвикани од рутински операции.
  • Ако користите Stackdriver, тогаш вклучете ги метриките на платформата GCP во вашите контролни табли. Поставете предупредувања за зависности од GCP.
  • Секогаш пропагирајте ги дојдовните траги. Дури и ако не сте вклучени во следењето, ова ќе им овозможи на услугите од пониско ниво да ги отстранат проблемите во производството.

Заштита и безбедност

  • Проверете дали сите надворешни врски се шифрирани.
  • Проверете дали вашите производствени проекти го имаат правилното поставување на IAM.
  • Користете мрежи за да изолирате групи на примери на виртуелни машини.
  • Користете VPN за безбедно поврзување со оддалечени мрежи.
  • Документирајте и следете го корисничкиот пристап до податоците. Осигурете се дека целиот кориснички пристап до податоците е ревидиран и евидентиран.
  • Осигурете се дека крајните точки за отстранување грешки се ограничени со ACL.
  • Дезинфицирајте го внесувањето на корисникот. Конфигурирајте ги ограничувањата на големината на носивоста за внесување на корисникот.
  • Проверете дали вашата услуга може селективно да го блокира дојдовниот сообраќај за поединечни корисници. Ова ќе ги блокира прекршувањата без да влијае на другите корисници.
  • Избегнувајте надворешни крајни точки кои иницираат многу внатрешни операции.

Планирање на капацитети

  • Документирајте како се размери вашата услуга. На пример: број на корисници, големина на дојдовен товар, број на дојдовни пораки.
  • Документирајте ги барањата за ресурси за вашата услуга. На пример: број на наменски примери на виртуелна машина, број на примери на Spanner, специјализиран хардвер како што се GPU или TPU.
  • Ограничувања на ресурсите на документот: тип на ресурси, регион итн.
  • Документирајте ограничувања на квоти за создавање нови ресурси. На пример, ограничување на бројот на GCE API барања ако го користите API за создавање нови примероци.
  • Размислете за извршување на тестови за оптоварување за да се анализира деградацијата на перформансите.

Тоа е се. Се гледаме на час!

Извор: www.habr.com

Додадете коментар