Класне відео! Моя думка - звільняти за факапи, то дурість, особливо, коли вони із-за технічної помилки, навпаки, команда отримала важливий досвід і зробила висновки.
@@DenysVasyliev мені сподобався підхід з google sre book, коли є певний бюджет даунтаймів, які не порушують sla, якщо ми близькі до межі, чи порушуємо sla - робимо паузу з новими фічами і фіксимо надійність, доки знов не зʼявиться бюджет, тоді знову нові фічі… і так по колу
@@DenysVasyliev мені колись сподобалася ідея з sre book, що має бути бюджет помилок/даунтаймів, який не повинен виходити за sla і якщо ми вичерпали наш бюджет, то працюємо над покращенням стабільності, а коли знов зʼявляється бюджет, то над новими фічами і так весь час балансуємо. P.S. Другий раз пишу комент, чомусь youtube попередній не опублікував.
В такому випадку можна говорити про звільнення. Це показує, що людина не зробила правильних висновків і не працює над своїми помилками. І бізнесу банально дешевше звільнити людину аніж піти на ризики майбутніх втрат через повторні помилки.
@@DenysVasyliev мені колись сподобалася ідея з sre book, що має бути бюджет помилок/даунтаймів, який не повинен виходити за SLA і якщо ми вичерпали наш бюджет, то працюємо над покращенням стабільності, а коли знов зʼявляється бюджет, то над новими фічами і так весь час балансуємо. P.S. Другий чи третій раз пишу комент, чомусь youtube попередні не опублікував.
НІколи не користувався Flux'ом. Але якщо пофантазувати, думаю, що можна провести аналогію з Тераформом та resource groups у Azure Поки щось буде у namespace, він просто буде видаляти ці ресурси, і тільки в останню чергу namespace Стосовно admission control - namespace спасе, але ресурси всередині наврядчи Можна спробувати заборонити delete ресурсів з ключовими labels, але дозволити update, щоб flux продовжив працювати ( але виглядає як костиль ;) )
щодо external-dns, він може перестворювати вже навіть існуючі записи, якщо ваш ingress controller перезапускався(ролінг апдейт), в моєму випадку це nginx-ingress-controller був, поставивши параметр в хельмі проблема ця зникла, на github external-dns навіть issue ці були: extraArgs: update-status-on-shutdown: "false"
Є ефемерні адреси, а є зарезервовані - перманентні. Коли балансер новий - він отримує ефемерну адресу, якщо конфігурацію не вказано інше. Далі можна переназначити, привʼязавши адресу "яку всі знають" до балансера cloud.google.com/kubernetes-engine/docs/how-to/load-balance-ingress
Дякую за постмортем, було дуже цікаво і повчально. Залишу декілька своїх коментарів: 1. Гарний кейс того що не треба тримати всі яйця в одній корзині. 2. Щодо повного вайпа проду, як зазначалось у відео, на мою думку трохи перебільшено, бо стореджі або їх стейт все таки залишився. 3. Чи є у вас DRP на такі чи подібні випадки?
1. Ну по факту це різні сорси. 2. Стораджі навіть якщо не збереглися, є снапшоти. Дату зберігати це ж нормально :) 3. BCP ми називаємо - це саме гнучкість інфри та аплікації. Зараз вона стала ще краще і ми можемо гарантувати відновлення в зазначені терміни, адже кластери також в коді.
Дякую за відео! Питання по Волту. А що у вас використовувалося як storage backend? Враховуючи, що Ви казали про втрату сікретів, які створювались не через код, то ресторнути волт не було із чого?
Ааа, все, зрозуміло, дякую за уточнення. Доречі як альтернативу VSO можна також External Secrets, там також буде «кеш через нативні кубернетіс сікрети» і на додачу підтримує і інші сікрет стораджі
2. В якості рішення вирішили створювати key-value yaml для ось таких от секретів і класти його поруч із terragrunt.hcl, в ньому використовуємо вбудовану sops_decrypt_file функцію і значення передаємо в інпути як звичайні терраформ змінні. Ну і волт секрет тф ресурси вже використовуть ці тф змінні.
Звільнення за один факап - це не правильно. Але якщо є повтори тоді питання до ліда - Чому? Й головне питання якщо бізнес приносить великі кошти тоді питання до архітектора Чому так?. Блю-грін проди це вже давно використовуемі рішення й тоді будь-який факап це вже не привід для звільнення. Гарні відео на каналі. Дякую!
Підтримую - всі помиляються і завдання ліда не зменшити ризики людського фактору (автоматизація, навчання), а апп повинен бути витривалим за архітектурою. 5 Whys - добра практика
Дивно було чути звільнення за факап при помилках налаштування днс. У нас одного разу в офісному влан дівчина розробник захотіла підняти собі vrrp разом з dhcp. Неналаштований dhcp призвело до наслідків. Я чув що її відправили здобувати ccna.
Лайк підписка. Пригадую як гтілба поклали овер дофіга "чогось". Було весело в онлайн режимі дивитись як то все відновлюють. І трохи флуду... не тримайте важливу інфу на SSD. рівно через два дні закінчення гарантії 1 TB 970 evo plus пішов спатки. Бекапи наше "все". Всім вдалого, мирнго дня.
@@sofia-p7d4t ну це дуже загадкова історія, гадаю. І ціна помилки, мабуть, то була таки помилка, доволі висока. Чи є десь в пабліку деталі, адже справа напевно гучна була?
і це я думав в той день взяти дейофф, адже почувався перегруженим. Сходив в басейн, повернувся і перед відпочинком заглянув у слак. Там вже інцидент мітінг йшов другу хвилину. Відпочив..
@@DenysVasyliev А посилання немає, AI вигадав цей флаг, сказавши потім, що зробив припущення що може існувати такий флаг, короче - просто обманув. А на питання нашо ти це зробив, він відповів, що просто не мав відповіді так вигадав... Отака от історія.😄
![[не]правильний DevOps](http://yt3.ggpht.com/4MiD0VlQK99CPMwFkYR81y9KmD8aYBIJ84NnzsA-o1mvTKHsFoR6iYgu_g0Fi3J8ePuRQHRNppw=s48-c-k-c0x00ffffff-no-rj)
![Як змусити себе працювати? | Три [не]прості кроки проти апатії | Ламаємо Win | Патчимо Gitlab та K8S](http://i.ytimg.com/vi/JAioWAJqPRo/mqdefault.jpg)
Класне відео!
Моя думка - звільняти за факапи, то дурість, особливо, коли вони із-за технічної помилки, навпаки, команда отримала важливий досвід і зробила висновки.
абсолютно підтримую. А як на Вашу думку, якщо подібний другий або третій факап - що робити?
@@DenysVasyliev мені сподобався підхід з google sre book, коли є певний бюджет даунтаймів, які не порушують sla, якщо ми близькі до межі, чи порушуємо sla - робимо паузу з новими фічами і фіксимо надійність, доки знов не зʼявиться бюджет, тоді знову нові фічі… і так по колу
@@DenysVasyliev мені колись сподобалася ідея з sre book, що має бути бюджет помилок/даунтаймів, який не повинен виходити за sla і якщо ми вичерпали наш бюджет, то працюємо над покращенням стабільності, а коли знов зʼявляється бюджет, то над новими фічами і так весь час балансуємо.
P.S. Другий раз пишу комент, чомусь youtube попередній не опублікував.
В такому випадку можна говорити про звільнення. Це показує, що людина не зробила правильних висновків і не працює над своїми помилками. І бізнесу банально дешевше звільнити людину аніж піти на ризики майбутніх втрат через повторні помилки.
@@DenysVasyliev мені колись сподобалася ідея з sre book, що має бути бюджет помилок/даунтаймів, який не повинен виходити за SLA і якщо ми вичерпали наш бюджет, то працюємо над покращенням стабільності, а коли знов зʼявляється бюджет, то над новими фічами і так весь час балансуємо.
P.S. Другий чи третій раз пишу комент, чомусь youtube попередні не опублікував.
Ну, блін, 2 години до повного рестору проду - навіть з проблемами відсутності деяких речей в коді - це дуже круто!
До речі, я, можливо, теж трохи параноік, і тому тримаю бд окремо від апки ;)
Бачу, що в цілому це досить вірний підхід, враховуючи ваш досвід
@@AT-rocket теж пропагую такий підхід :)
Мій улюблений DevOps blogger, дякую!
Крутий кейс, дякую, не кожен зможе розповісти про такий глобальний факап з продом. Христос Воскрес!
НІколи не користувався Flux'ом. Але якщо пофантазувати, думаю, що можна провести аналогію з Тераформом та resource groups у Azure
Поки щось буде у namespace, він просто буде видаляти ці ресурси, і тільки в останню чергу namespace
Стосовно admission control - namespace спасе, але ресурси всередині наврядчи
Можна спробувати заборонити delete ресурсів з ключовими labels, але дозволити update, щоб flux продовжив працювати ( але виглядає як костиль ;) )
дякую, це варіанти і вони корисні для глядачів адже у кожного різний досвід
щодо external-dns, він може перестворювати вже навіть існуючі записи, якщо ваш ingress controller перезапускався(ролінг апдейт), в моєму випадку це nginx-ingress-controller був, поставивши параметр в хельмі проблема ця зникла, на github external-dns навіть issue ці були:
extraArgs:
update-status-on-shutdown: "false"
Дякую - подивлюся на issues!
від nobody blame до ми звільняли за помилку, можливо саме блейм допоможе)))
то різні часові проміжки: спочатку звільняли, а зараз більше цінують людей і практики змінились.
Вітаю. Про лоадбалансери і ДНС не зрозуміло. Що значить 'зарезервована' ІР замінена на 'нову' ІР ? І як ви це виправили ?
Є ефемерні адреси, а є зарезервовані - перманентні. Коли балансер новий - він отримує ефемерну адресу, якщо конфігурацію не вказано інше. Далі можна переназначити, привʼязавши адресу "яку всі знають" до балансера cloud.google.com/kubernetes-engine/docs/how-to/load-balance-ingress
Дякую за постмортем, було дуже цікаво і повчально.
Залишу декілька своїх коментарів:
1. Гарний кейс того що не треба тримати всі яйця в одній корзині.
2. Щодо повного вайпа проду, як зазначалось у відео, на мою думку трохи перебільшено, бо стореджі або їх стейт все таки залишився.
3. Чи є у вас DRP на такі чи подібні випадки?
1. Ну по факту це різні сорси.
2. Стораджі навіть якщо не збереглися, є снапшоти. Дату зберігати це ж нормально :)
3. BCP ми називаємо - це саме гнучкість інфри та аплікації. Зараз вона стала ще краще і ми можемо гарантувати відновлення в зазначені терміни, адже кластери також в коді.
Крутезне відео. Втім як завжди. Дякую
Дякую!
Дякую за відео!
Питання по Волту. А що у вас використовувалося як storage backend? Враховуючи, що Ви казали про втрату сікретів, які створювались не через код, то ресторнути волт не було із чого?
волт на клауд сторадж. це окремий сетап і з ним все ок. То про VSO йшлося
- компонент для волта
Ааа, все, зрозуміло, дякую за уточнення. Доречі як альтернативу VSO можна також External Secrets, там також буде «кеш через нативні кубернетіс сікрети» і на додачу підтримує і інші сікрет стораджі
2. В якості рішення вирішили створювати key-value yaml для ось таких от секретів і класти його поруч із terragrunt.hcl, в ньому використовуємо вбудовану sops_decrypt_file функцію і значення передаємо в інпути як звичайні терраформ змінні. Ну і волт секрет тф ресурси вже використовуть ці тф змінні.
хороший контент 👍
при нагоді було б цікаво почути, як, для чого використовуєте арго воркфлоу
в основному МЛ. дякую за ідею!
@@DenysVasyliev
доречі, за те як використовуєш LM для себе теж цікаво ;)
@@yuriykutsiy3781 дивись епізод про Матрицю
там мало, що є про сам сетап)
Звільнення за один факап - це не правильно. Але якщо є повтори тоді питання до ліда - Чому? Й головне питання якщо бізнес приносить великі кошти тоді питання до архітектора Чому так?. Блю-грін проди це вже давно використовуемі рішення й тоді будь-який факап це вже не привід для звільнення.
Гарні відео на каналі. Дякую!
Підтримую - всі помиляються і завдання ліда не зменшити ризики людського фактору (автоматизація, навчання), а апп повинен бути витривалим за архітектурою. 5 Whys - добра практика
Дивно було чути звільнення за факап при помилках налаштування днс. У нас одного разу в офісному влан дівчина розробник захотіла підняти собі vrrp разом з dhcp. Неналаштований dhcp призвело до наслідків. Я чув що її відправили здобувати ccna.
В нас було жорсткий відбір до команди NOC і слід зауважити, для неї то був випробувальний термін
Ну вона показала де є проблеми з архітектурою, acl, snooping... Це мало произвести тільки до алерту .
Лайк підписка.
Пригадую як гтілба поклали овер дофіга "чогось". Було весело в онлайн режимі дивитись як то все відновлюють.
І трохи флуду... не тримайте важливу інфу на SSD. рівно через два дні закінчення гарантії 1 TB 970 evo plus пішов спатки.
Бекапи наше "все".
Всім вдалого, мирнго дня.
Так було, пригадую. Дякую щодо ssd. А якщо вони не використовуються (не підключені постійно) - це ж повинно бути безпечно?
@@DenysVasyliev нууу... мої девопси сказали: "тримай власний клауд (бажано декілька) та HDD"
Сумно, але це життя ;)
Коли я стерла прод - переїхала до Польщі, і змінила ім'я.
ого. це реальна історія?
@@DenysVasyliev На жаль. Це було на різдво 2021, тому скориставшись війною, я переїхала до Польщі.
@@sofia-p7d4t судячи з того що ім'я довелося змінити це сумна історія чи це не пов'язано?
@@DenysVasyliev ну, коштувала клієнту к-ка мільяонів доларів, як мені сказали.
@@sofia-p7d4t ну це дуже загадкова історія, гадаю. І ціна помилки, мабуть, то була таки помилка, доволі висока. Чи є десь в пабліку деталі, адже справа напевно гучна була?
Зжалося і до кінця відео не розжалося😂
ох! вибачте, але знайоме відчуття:)
цікавий кейс - але бляха жорсткий досвід)
і це я думав в той день взяти дейофф, адже почувався перегруженим. Сходив в басейн, повернувся і перед відпочинком заглянув у слак. Там вже інцидент мітінг йшов другу хвилину. Відпочив..
.spec.prune: true -> .spec.prune: false
👻
Звільнення за факапи) тобто оплатили такою ціною йому досвід і віддали конкуренту?))
ну можна використовувати як метод боротьби з конкурентами :)
флаг --recreation-policy never
А можна посилання на документацію з цією опцією?
Насправді, це spec.prune - github.com/fluxcd/flux2/discussions/3743
@@DenysVasyliev А посилання немає, AI вигадав цей флаг, сказавши потім, що зробив припущення що може існувати такий флаг, короче - просто обманув. А на питання нашо ти це зробив, він відповів, що просто не мав відповіді так вигадав... Отака от історія.😄
@@voyauger я десь так в зрозумів. Воно так треновані, не розчаровувати замовника:)