Факап, який не веде до людських втрат - не факап, а просто репутацiнi або грошовi втрати. Знайомий devops розповiдав (його команда супортила сервери для бiо стимуляторiв для сердця), пiд час одного ремоут апдейта щось пiшло не так (хтось нафакапив з бiлдом i вчасно не вiдкатив) - стимулятори вимкнулись, що призвело до декiлькох смертей.
Дивлюсь вас і самого так підмиває розповісти свої 2 факапи (сподіваюсь, останні)... Може б ви якось запрошували різних джунів або міддлів голосом до себе? Такий (е)баут формат)))))
Ну це був крутий випуск, цікаво було почути, особливо про факапи) Окрему відзначу, що гумор покращує випуски, особливо якщо вони довгі Також відчутно, що спікери працюють над вимовою, як вони говорять Приємно було слухати, чудовий випуск
Якось дуже поверхнево і зверхньо пройшлися темою адмінів. Адміни бувають не лише офісні, а й ті, хто працюють в айті компаніях, наприклад у датацентрах AWS чи різних хостингах. Людям важко побачити різницю між такими опсами і девопсами, бо різниці насправді не так багато. Так, змінився підхід, методологія, технології, але девопс інженер це той самий айтішний сисадмін, навчений використовувати нові підходи в розробці та підтримці інфраструктури. Якось так "історично склалося", що нових сісів стали називати девопсами, загалом яка різниця, головне, щоб люди не плуталися і розуміли, що девопс це Ops, а не якась нова професія, взята зі стелі (як дехто вважає). Чудове інтерв'ю на цю тему є в Anywhere Club з Віктором Ведмичем, на жаль російською. Очікую від вас такого рівня аналізу. Дякую за відео та розвиток українського Девопс ком'юніті!
Привіт. Дякую за комент. Переглянув я Anywhere Club. В них подкаст на 3 години. А в нас ліміт на годину. Будемо старатися, або виносити як окремі відео "на тему". До речі, "ті, хто працюють в айті компаніях, наприклад у датацентрах AWS", вони якраз і генерують прибуток компанії, тому це якраз можна віднести більше до delivery. Адміни, якщо ви це читаєте, поділіться своїми рутинними тасками які у вас найчастіше травляються на роботі?
неймовірно вдячний! як початківцю-менеджеру зрозуміти факапи було складно, але ось про контроль версій розжували дуже круто! ще й подали ретроспективний аналіз! дуже подобається подача! дякую!
ДевОпс - не людина. Це підхід в розробці. Коли девелопер ще думає як його код буде крутитись і в якій системі. Тобто пише не для "у мене на машині все працює", а знає що це буде в умовних куберах і може сам написати (підправити) YAML щоб перевірити. Те, що ви розказуєте це просто сисадміни (опси) зі спеціалізацією. Написання скриптів, щоб обмазати кубер - це не девелопмент, а підтримка. Я б це називав "інженер з систем ХХХХ", але ж хочеться називатись модним словом, хоча від Дев в цій професії майже нічого. Ну і да, сисадмін, якого продають стає девопсом - це просто якийсь маркетинговий булшіт.
В пілотному випуску ми говорили що це інженер + методологія. Але сьогодні це вже дуже розмито. Можна називатися клауд інженером, реліз інженером, платформ інженкром, чи вотеваопс :) Головне щоб ти був щасливий(ва) 😊 А чому немає спільного з дев? - Процеси розроби такі ж. - робоче середовище таке ж - код пишеться, не завжди олп, але це ж не головне, правда? - можна працювати по спринтах. Естімейти та сторіпоінти - багато хто пише на го, пайтоні, чи .неті. Тут можна спорити довго. Але, залишайте коменти і ми їх обговоримо в наступному епізоді 😌
@@apprecode Тут є тонка межа. Одна справа - бізнес-логіка, інша - підтримка середовища де ця логіка крутиться. В ТЕОРІЇ бізнес-логіка має мати змогу прозоро переходити з одного середовища виконання на інше. Це і є слідування методології ДевОпс. Ідея в тому, що розробка - це створення нового (іноді принципово), а робота інфраструктурного інженера - перебирання готових "кубиків" технології, щоб забезпечити вимоги (програми, відмовостійкості, тощо), тобто саме "нового" там мало, скоріше "я знаю як треба" і намагання з готових кубиків скласти то саме ЩАСТЯ. І те, що кубики іноді доводиться точити не значить, що це щось принципово нове, бо результат вже відомий. Те, що ви знайшли новий спосіб зробити пензлик зі швабри і так само пофарбували паркан не робить вас художником. Тут може здатись, що я десь принижую роботу опсів в порівнянні з девами, це не так, насправді. У кожного своя роль. Парканів все ж більше ніж музеїв В якомусь сенсі дуже грубо, опси не займаються бізнес-логікою, але забезпечують її виконання. Для аналогії, в будівництві є архітектори, проектанти, будівники різних спеціалізацій і інженери з обслуговування. Це трохи різні люди.
CircleCi наразі мені найбільше подобається з усіх CI as a service. GitHub actions - do not repeat yourself погано реалізовано з коробки. Debug console для pipeline який валиться теж відсутній.
Погоджуюся. Мені ще не подобається що самі по собі екшини це як NPM пакет. Ти його завантажуєш, білдаєш (часто це докефайл) і тоді він виконується. Хороший спосіб забрати в тебе побільше кредитних хвилин. Зате для пересічного стартап проєкту цього більш ніж достатньо. Для складних великих проєктів, краще користуватися старим добрим башом чи пайтоном.
DevOps - це сис.адмін здорової людини. Бо ще до того, як формалізували визначення ДевОпс практик, нормальні сисадміни займались тим же: поєднували команди/відділи, автоматизували і будували інфраструктуру (фактично реалізовували ту схему безкінечного циклу)
48:43 Я слухаю на швидкості 1.5х і офігіваю, як Валєра. Чувак читає якесь закляття, щоб визвати Вельзевула. Він не розуміє всієї піраміди CI/CD. Працюю сисадміном понад 10 років. Таку діч з різних мов слухати важко. Середовища dev, test, stage i prod у великих компаніях створені для мінімізації кількості і ціни факапів. Це не бюрократія -- це мінімізація збитків. За падіння прода відповідає адміністратор СИСТЕМИ, а не девелопери (які мержать по 5 разів на день в гілку master). Саме тому СИСАДМІН ЗАЛИВАЄ РЕЛІЗ на прод після всіх тестів, а не девелопери. Замовнику пофіг на девелоперів -- замовник має на руках SLA, в якому серед виконавців є СИСАДМІН.
Trunk based development підійде максимум для мініатюрних команд, а для великих команд ця методика породить лише хаос, для прикладу стане проблематично навіть поділитися своїм ще не готовим кодом з іншими членами команди щоб не споганити спільну гілку. Крім того пуш в мастер мав би бути в ручну одобрений, щоб гарантувати вищу якість коду, бо просто напросто хтось може забути написати важливий тест. Як на мене для серйозних проектів Trunk based development це безглуздя
1:18:00 Кастомізація Дженкінса це великий "плюс". Всю кастомізацію можна задокументувати, а для Дженкінса її там не багато. Груві досить проста мова, я через годину гугління вже писав короткі сценарії. Не треба там створювати Франкенштейна. Кастомізація -- це не проблема старого ДевОпса, коли після звільнення роботодавець повинен знайти нового ДевОпса, який розбереться в Груві-коді. Нові розробники чомусь розбираються в java-коді попередників. А чим новий ДевОпс гірший за нового розробника на інтелектуальному рівні?
@@dmytrostriletskyi спасибо) у меня будут и другие вопросы по этой теме. Мы уходим от гит флоу к транку, но немного в другом виде. И мне будет интересно подробнее изучить ваш подход.
Ну дуже погано. Хто починає подкаст з факапів? Ви тільки представились, 99.9% глядачів вас не знають - чому їм цікавим повинні бути історії ваших провалів зі старту? Ну продумайте хоч трошки драматургію… такі теми потрібно піднімати, коли вже всі вас ліпше дізнались. Далі: ваші історії зовсім не цікаві і не репрезентативні з точки зору висновків. Це просто скиглення штибу "подивіться, які ми(вони) рукожопи". Чому вони вчать: не робити паролі 1234qwerty та не майнити на АВС? Ну не обов’язково ж лизати сковорідку щоб зрозуміти що вона гаряча…
А як факапили ви?
Моцно
Факап, який не веде до людських втрат - не факап, а просто репутацiнi або грошовi втрати.
Знайомий devops розповiдав (його команда супортила сервери для бiо стимуляторiв для сердця), пiд час одного ремоут апдейта щось пiшло не так (хтось нафакапив з бiлдом i вчасно не вiдкатив) - стимулятори вимкнулись, що призвело до декiлькох смертей.
@@ivankonosov Брехня. Це він пересказав серію з серіалу на Нетфліксі.
Дивлюсь вас і самого так підмиває розповісти свої 2 факапи (сподіваюсь, останні)... Може б ви якось запрошували різних джунів або міддлів голосом до себе? Такий (е)баут формат)))))
Гарний епізод, продовжуйте! 😊
дуже файний подкаст вийшов, підняли гарні топіки, продовжуйте!
Ну це був крутий випуск, цікаво було почути, особливо про факапи)
Окрему відзначу, що гумор покращує випуски, особливо якщо вони довгі
Також відчутно, що спікери працюють над вимовою, як вони говорять
Приємно було слухати, чудовий випуск
Якось дуже поверхнево і зверхньо пройшлися темою адмінів. Адміни бувають не лише офісні, а й ті, хто працюють в айті компаніях, наприклад у датацентрах AWS чи різних хостингах. Людям важко побачити різницю між такими опсами і девопсами, бо різниці насправді не так багато. Так, змінився підхід, методологія, технології, але девопс інженер це той самий айтішний сисадмін, навчений використовувати нові підходи в розробці та підтримці інфраструктури. Якось так "історично склалося", що нових сісів стали називати девопсами, загалом яка різниця, головне, щоб люди не плуталися і розуміли, що девопс це Ops, а не якась нова професія, взята зі стелі (як дехто вважає). Чудове інтерв'ю на цю тему є в Anywhere Club з Віктором Ведмичем, на жаль російською. Очікую від вас такого рівня аналізу. Дякую за відео та розвиток українського Девопс ком'юніті!
Привіт. Дякую за комент.
Переглянув я Anywhere Club. В них подкаст на 3 години. А в нас ліміт на годину. Будемо старатися, або виносити як окремі відео "на тему".
До речі, "ті, хто працюють в айті компаніях, наприклад у датацентрах AWS", вони якраз і генерують прибуток компанії, тому це якраз можна віднести більше до delivery.
Адміни, якщо ви це читаєте, поділіться своїми рутинними тасками які у вас найчастіше травляються на роботі?
Прикольний випуск!
неймовірно вдячний!
як початківцю-менеджеру зрозуміти факапи було складно, але ось про контроль версій розжували дуже круто! ще й подали ретроспективний аналіз!
дуже подобається подача! дякую!
ДевОпс - не людина. Це підхід в розробці. Коли девелопер ще думає як його код буде крутитись і в якій системі. Тобто пише не для "у мене на машині все працює", а знає що це буде в умовних куберах і може сам написати (підправити) YAML щоб перевірити.
Те, що ви розказуєте це просто сисадміни (опси) зі спеціалізацією. Написання скриптів, щоб обмазати кубер - це не девелопмент, а підтримка. Я б це називав "інженер з систем ХХХХ", але ж хочеться називатись модним словом, хоча від Дев в цій професії майже нічого.
Ну і да, сисадмін, якого продають стає девопсом - це просто якийсь маркетинговий булшіт.
Згоден із вами. Важко бути не згодним із визначенням :)
Здивований, що «девопси» не знають, що таке девопс 😂
В пілотному випуску ми говорили що це інженер + методологія. Але сьогодні це вже дуже розмито.
Можна називатися клауд інженером, реліз інженером, платформ інженкром, чи вотеваопс :)
Головне щоб ти був щасливий(ва) 😊
А чому немає спільного з дев?
- Процеси розроби такі ж.
- робоче середовище таке ж
- код пишеться, не завжди олп, але це ж не головне, правда?
- можна працювати по спринтах. Естімейти та сторіпоінти
- багато хто пише на го, пайтоні, чи .неті.
Тут можна спорити довго.
Але, залишайте коменти і ми їх обговоримо в наступному епізоді 😌
@@apprecode
Тут є тонка межа. Одна справа - бізнес-логіка, інша - підтримка середовища де ця логіка крутиться. В ТЕОРІЇ бізнес-логіка має мати змогу прозоро переходити з одного середовища виконання на інше. Це і є слідування методології ДевОпс.
Ідея в тому, що розробка - це створення нового (іноді принципово), а робота інфраструктурного інженера - перебирання готових "кубиків" технології, щоб забезпечити вимоги (програми, відмовостійкості, тощо), тобто саме "нового" там мало, скоріше "я знаю як треба" і намагання з готових кубиків скласти то саме ЩАСТЯ. І те, що кубики іноді доводиться точити не значить, що це щось принципово нове, бо результат вже відомий. Те, що ви знайшли новий спосіб зробити пензлик зі швабри і так само пофарбували паркан не робить вас художником.
Тут може здатись, що я десь принижую роботу опсів в порівнянні з девами, це не так, насправді. У кожного своя роль. Парканів все ж більше ніж музеїв
В якомусь сенсі дуже грубо, опси не займаються бізнес-логікою, але забезпечують її виконання.
Для аналогії, в будівництві є архітектори, проектанти, будівники різних спеціалізацій і інженери з обслуговування.
Це трохи різні люди.
Це на мою думку, найцікавіше відео у доу
Чи буде подкаст з найпопулярнішими тасками?
Взяли в беклог :)
Сінйор не знають пр AWS Budjet? Ви що серьозно?
Це перше, що треба налаштовувати
Trunk based щось таке що наголову налізає, але можливо воно реально працює
А давайте згенеруємо приклади як можна використати CI в системному адмініструванні. Є ідеї?
Запуск скриптів по якомусь екшену?)
Легко. Тестуй анзібл плейбуки для розгортання того що адмініструється )
CircleCi наразі мені найбільше подобається з усіх CI as a service. GitHub actions - do not repeat yourself погано реалізовано з коробки. Debug console для pipeline який валиться теж відсутній.
Погоджуюся. Мені ще не подобається що самі по собі екшини це як NPM пакет. Ти його завантажуєш, білдаєш (часто це докефайл) і тоді він виконується. Хороший спосіб забрати в тебе побільше кредитних хвилин.
Зате для пересічного стартап проєкту цього більш ніж достатньо. Для складних великих проєктів, краще користуватися старим добрим башом чи пайтоном.
DevOps - це сис.адмін здорової людини. Бо ще до того, як формалізували визначення ДевОпс практик, нормальні сисадміни займались тим же: поєднували команди/відділи, автоматизували і будували інфраструктуру (фактично реалізовували ту схему безкінечного циклу)
48:43 Я слухаю на швидкості 1.5х і офігіваю, як Валєра. Чувак читає якесь закляття, щоб визвати Вельзевула. Він не розуміє всієї піраміди CI/CD.
Працюю сисадміном понад 10 років. Таку діч з різних мов слухати важко.
Середовища dev, test, stage i prod у великих компаніях створені для мінімізації кількості і ціни факапів. Це не бюрократія -- це мінімізація збитків.
За падіння прода відповідає адміністратор СИСТЕМИ, а не девелопери (які мержать по 5 разів на день в гілку master). Саме тому СИСАДМІН ЗАЛИВАЄ РЕЛІЗ на прод після всіх тестів, а не девелопери.
Замовнику пофіг на девелоперів -- замовник має на руках SLA, в якому серед виконавців є СИСАДМІН.
Trunk based❤
Думаю варто робити більш довгі випуски бо години мало
кажуть що не можна))
Trunk based development підійде максимум для мініатюрних команд, а для великих команд ця методика породить лише хаос, для прикладу стане проблематично навіть поділитися своїм ще не готовим кодом з іншими членами команди щоб не споганити спільну гілку.
Крім того пуш в мастер мав би бути в ручну одобрений, щоб гарантувати вищу якість коду, бо просто напросто хтось може забути написати важливий тест.
Як на мене для серйозних проектів Trunk based development це безглуздя
Найс!
1:18:00 Кастомізація Дженкінса це великий "плюс". Всю кастомізацію можна задокументувати, а для Дженкінса її там не багато. Груві досить проста мова, я через годину гугління вже писав короткі сценарії. Не треба там створювати Франкенштейна.
Кастомізація -- це не проблема старого ДевОпса, коли після звільнення роботодавець повинен знайти нового ДевОпса, який розбереться в Груві-коді. Нові розробники чомусь розбираються в java-коді попередників. А чим новий ДевОпс гірший за нового розробника на інтелектуальному рівні?
Девопс, котрий запустив майнінг на AWS - ти мій герой, гаркнув в голосяндру
По aws глобальні права повинні бути у архітектора а неу адміністратора.
Транк бейсд схема требует более детального обсуждения. И имхо это был наиболее интересный топик за сегодня. Мало времени выделили на это.
тёплый ламповый выпуск ❤
То есть при описанном транк методе люди вечером и в пятницу ничего не мержат?)
Це більше про антикрихкість, а не про TBD. Я запишу це собі в нотатки і ми зробимо це окремим невеликим топіком в якомусь епізоді, дякую!
@@dmytrostriletskyi спасибо) у меня будут и другие вопросы по этой теме. Мы уходим от гит флоу к транку, но немного в другом виде. И мне будет интересно подробнее изучить ваш подход.
Trunk Based Development is the only way of development 😄
Якась пісна херня, а не подкаст. Дівопс Інженер - верне від цього терміну, який просто сподобався ХР-ам з лінкд-іну, і понеслась.
Ну дуже погано. Хто починає подкаст з факапів? Ви тільки представились, 99.9% глядачів вас не знають - чому їм цікавим повинні бути історії ваших провалів зі старту? Ну продумайте хоч трошки драматургію… такі теми потрібно піднімати, коли вже всі вас ліпше дізнались. Далі: ваші історії зовсім не цікаві і не репрезентативні з точки зору висновків. Це просто скиглення штибу "подивіться, які ми(вони) рукожопи". Чому вони вчать: не робити паролі 1234qwerty та не майнити на АВС? Ну не обов’язково ж лизати сковорідку щоб зрозуміти що вона гаряча…
Фу, назва не креативна, дизлайк
А були... Були...
Як в айті відрізнити хлопця від дівчини ? Відповідь: в хлопців є борода. Без бороди не факт, що то хлопець 😅