текст перекладу
Або як ми можемо використовувати це як консультанти для підвищення продуктивності, забезпечення безпеки та впровадження найкращих практик для наших клієнтів.
На LinkedIn я побачив цікаву публікацію від April Yoho (як завжди), де обговорюється сьогоднішня тема: GiHub Well-Architected Framework.
Прочитавши цей вебсайт, я дуже швидко подумав: Ого! Це виглядає чудово! Назва дуже схожа на Azure Well Architected Framework, і здається, що ми можемо використовувати це так само!
Отже, це публікація про те, що потрібно знати про цей новий фреймворк.
Велика сила п’яти стовпів і супутня документація
Про що йдеться в кількох словах
Коротко кажучи, це фреймворк, що містить усі найкращі практики, рекомендації перевірених списків, пояснення антипатернів для всіх, хто працює з GitHub або практиками DevOps. Цю написану документацію можна використовувати для проведення початкової оцінки або для впровадження правильних практик з самого початку, коли організація вирішить перейти на GitHub.
Ця публікація не має на меті детально пояснити кожен аспект цієї документації, але я хочу підкреслити, чому це важливо, як її використовувати і надати кілька ідей для будь-якого зацікавленого учасника цього процесу.
Ми говоримо про фреймворк, і, як і Scrum (який НЕ є методологією, будь ласка, не робіть помилки і ознайомтесь з офіційним визначенням), GitHub Well-Architected фреймворк дає вам підхід, культуру та мислення, які можна адаптувати відповідно до ваших потреб. Пам'ятайте, що це документ, який постійно оновлюється: тому примітки до випусків відображатимуть усі зміни, внесені платформою (наприклад, щодо ІТ).
Більше того, цей документ не тільки технічний, а й практичний, пояснюючи культуру, добрі практики для впровадження та кілька перевірених списків. Я не рекомендую впроваджувати кожну окрему рекомендацію, але він дає вам ідеї, показує нові цілі, які ви можете реалізувати в довгостроковій перспективі, або може бути хорошим способом заглянути назад і запитати себе: чи обрали ми правильний шлях?
Чотири стовпи, охоплені цим фреймворком
Ось швидке пояснення п’яти основних стовпів, на які орієнтований цей фреймворк (так само, як Azure має свої п’ять стовпів: Надійність, Безпека, Оптимізація витрат, Операційна досконалість, ефективність продуктивності).
Отже, п’ять стовпів:
1 Продуктивність
Все стосується того, як прискорити випуски програмного забезпечення за допомогою автоматизації, CI/CD пайплайнів і тим самим покращити Time-to-Market для бізнесу/клієнтів.
2 Співпраця
Це стосується інструментів DevOps і культури, яку кожен член команди повинен підтримувати для ефективної роботи системи, сильної команди, інноваційної культури. Цей стовп описує pull request, code review, проектні дошки та інші інструменти для співпраці, надані GitHub.
3 Безпека додатків
Це стосується забезпечення безпеки наших даних або чутливої інформації: ця частина описує відповідність стандартам, проактивність, загрози безпеці і забезпечення управління ризиками на всіх етапах життєвого циклу розробки. Тут є такі функції, як Dependabot, security advisories та code scanning.
4 Управління
Це стосується того, як організація виконує і дотримується своїх власних політик (дозволи, контроль доступу, журнали аудиту).
текст перекладу
Зазвичай це вже надходить з хмари або ІТ-управління, і це не нова тема.
5 Архітектура
Це технічний стовп, що стосується дизайну та того, як структурувати ваш GitHub-розвиток для вирішення проблем масштабованості, надійності та ефективності.
П'ять стовпів фреймворку GitHub Well-Architected
Як структуровано цей фреймворк?
Ця схема показує, як цей документ організований у зрозумілий спосіб: ви можете побачити п’ять стовпів, що містять посилання на документацію GitHub, присвячений перевірений список, який ви вже можете використовувати, деякі приклади сценаріїв та принципи дизайну, присвячені кожному з цих аспектів.
Дійсно, кожен стовп має свої Принципи дизайну, які надають більше деталей залежно від рівня зрілості: "Початковий", "Зрілий" або "Розвинений". Таким чином, ви можете вибрати правильну інформацію, залежно від того, на якому етапі ви знаходитеся на шляху до впровадження DevOps.
Наприклад, ви можете впровадити добрі практики відновлення після катастроф (Принцип дизайну архітектури) на рівні "Зрілий", якщо у вас вже є базова лінія, або зробити новий крок щодо "Прозорості" для вашої команди, якщо ви вважаєте, що вже досягли "доброї" рівня.
Загальні області спільні, але є спеціальні принципи дизайну для кожного стовпа
Мої рекомендації щодо цього фреймворку
Для консультантів DevOps або експертів, яким потрібно провести оцінку
Якщо вас попросили провести оцінку практик DevOps, подивіться, що вже зроблено добре, визначте області для покращення або вкажіть на те, що відсутнє або не працює: використовуйте цей фреймворк як хороший план для комунікації та презентації результатів. Це офіційна документація, надана GitHub та спільнотою, тому можна бути впевненими. До речі, я вже використовую Azure WAF і тут філософія та сама.
Перевірені списки, які надаються, є чудовим інструментом для проведення інтерв’ю, забезпечення того, що кожна тема була охоплена, і ви не пропустили нічого. Ви можете легко помістити їх у файл Excel і створити зведену таблицю, що вимірює, де ви зараз перебуваєте, та порівнювати досягнення на основі часової шкали. Пам'ятайте, що велика мета повинна бути S.M.A.R.T, тобто вимірною.
Для лідерів DevOps, які хочуть покращити свою організацію, випускати програмне забезпечення з більшою якістю та знижувати ризики.
Ніхто не може знати все про таку складну тему, як DevOps: це поєднання глибокої технічної експертизи, хороших практик, досвіду та культури компанії. Все змінюється дуже швидко, тому такий підхід і перевірені списки допомагають людям залишатися на передовій хороших практик і дають вам бачення та цілі для досягнення. Ці цілі повинні бути спільними для кожного учасника процесу, від керівництва (наприклад, спонсора) до членів команди розробників чи команд мережевої безпеки, бізнес-інфраструктури.
Моя рекомендація не полягає в тому, щоб досягти "Розвиненого" рівня кожного з Принципів дизайну, а скоріше адаптувати їх залежно від ваших потреб, бюджету, можливостей і поточних навичок людей.
Інша частина — це “Anti Pattern” частина: будь ласка, подивіться, і ви будете здивовані. Наприклад, GitHub не рекомендує мати кілька організацій без потреби через складність та накладні витрати на управління дозволами.
текст перекладу
Я вже бачу багато організацій, бо ми маємо ілюзію, що це принесе більше меж безпеки, але насправді це лише створює плутанину, коли мова йде про управління та впровадження CICD пайплайнів.
У висновку
Сподіваюся побачити наступні версії цього фреймворку, нові інструменти, які можуть бути випущені (як, наприклад, файл Excel для перевірочного списку Azure), а також відгуки від спільноти!
Щиро дякую за те, що прочитали цю статтю, сподіваюся, вона буде корисною, і не соромтеся залишати коментарі!
Перекладено з: GitHub Well-Architected Framework: what you need to know and use it