А як факапили ви?

@Youtube123Viewer

11 ай бұрын

Моцно

@ivankonosov

11 ай бұрын

Факап, який не веде до людських втрат - не факап, а просто репутацiнi або грошовi втрати. Знайомий devops розповiдав (його команда супортила сервери для бiо стимуляторiв для сердця), пiд час одного ремоут апдейта щось пiшло не так (хтось нафакапив з бiлдом i вчасно не вiдкатив) - стимулятори вимкнулись, що призвело до декiлькох смертей.

@tak_treba

11 ай бұрын

@@ivankonosov Брехня. Це він пересказав серію з серіалу на Нетфліксі.

@takashoty

5 ай бұрын

Дивлюсь вас і самого так підмиває розповісти свої 2 факапи (сподіваюсь, останні)... Може б ви якось запрошували різних джунів або міддлів голосом до себе? Такий (е)баут формат)))))

Гарний епізод, продовжуйте! 😊

дуже файний подкаст вийшов, підняли гарні топіки, продовжуйте!

Прикольний випуск!

Ну це був крутий випуск, цікаво було почути, особливо про факапи) Окрему відзначу, що гумор покращує випуски, особливо якщо вони довгі Також відчутно, що спікери працюють над вимовою, як вони говорять Приємно було слухати, чудовий випуск

Якось дуже поверхнево і зверхньо пройшлися темою адмінів. Адміни бувають не лише офісні, а й ті, хто працюють в айті компаніях, наприклад у датацентрах AWS чи різних хостингах. Людям важко побачити різницю між такими опсами і девопсами, бо різниці насправді не так багато. Так, змінився підхід, методологія, технології, але девопс інженер це той самий айтішний сисадмін, навчений використовувати нові підходи в розробці та підтримці інфраструктури. Якось так "історично склалося", що нових сісів стали називати девопсами, загалом яка різниця, головне, щоб люди не плуталися і розуміли, що девопс це Ops, а не якась нова професія, взята зі стелі (як дехто вважає). Чудове інтерв'ю на цю тему є в Anywhere Club з Віктором Ведмичем, на жаль російською. Очікую від вас такого рівня аналізу. Дякую за відео та розвиток українського Девопс ком'юніті!

@apprecode

11 ай бұрын

Привіт. Дякую за комент. Переглянув я Anywhere Club. В них подкаст на 3 години. А в нас ліміт на годину. Будемо старатися, або виносити як окремі відео "на тему". До речі, "ті, хто працюють в айті компаніях, наприклад у датацентрах AWS", вони якраз і генерують прибуток компанії, тому це якраз можна віднести більше до delivery. Адміни, якщо ви це читаєте, поділіться своїми рутинними тасками які у вас найчастіше травляються на роботі?

неймовірно вдячний! як початківцю-менеджеру зрозуміти факапи було складно, але ось про контроль версій розжували дуже круто! ще й подали ретроспективний аналіз! дуже подобається подача! дякую!

Це на мою думку, найцікавіше відео у доу

Trunk based❤

Trunk based щось таке що наголову налізає, але можливо воно реально працює

тёплый ламповый выпуск ❤

Чи буде подкаст з найпопулярнішими тасками?

@apprecode

11 ай бұрын

Взяли в беклог :)

Найс!

DevOps - це сис.адмін здорової людини. Бо ще до того, як формалізували визначення ДевОпс практик, нормальні сисадміни займались тим же: поєднували команди/відділи, автоматизували і будували інфраструктуру (фактично реалізовували ту схему безкінечного циклу)

ДевОпс - не людина. Це підхід в розробці. Коли девелопер ще думає як його код буде крутитись і в якій системі. Тобто пише не для "у мене на машині все працює", а знає що це буде в умовних куберах і може сам написати (підправити) YAML щоб перевірити. Те, що ви розказуєте це просто сисадміни (опси) зі спеціалізацією. Написання скриптів, щоб обмазати кубер - це не девелопмент, а підтримка. Я б це називав "інженер з систем ХХХХ", але ж хочеться називатись модним словом, хоча від Дев в цій професії майже нічого. Ну і да, сисадмін, якого продають стає девопсом - це просто якийсь маркетинговий булшіт.

@ipovos

11 ай бұрын

Згоден із вами. Важко бути не згодним із визначенням :) Здивований, що «девопси» не знають, що таке девопс 😂

@apprecode

11 ай бұрын

В пілотному випуску ми говорили що це інженер + методологія. Але сьогодні це вже дуже розмито. Можна називатися клауд інженером, реліз інженером, платформ інженкром, чи вотеваопс :) Головне щоб ти був щасливий(ва) 😊 А чому немає спільного з дев? - Процеси розроби такі ж. - робоче середовище таке ж - код пишеться, не завжди олп, але це ж не головне, правда? - можна працювати по спринтах. Естімейти та сторіпоінти - багато хто пише на го, пайтоні, чи .неті. Тут можна спорити довго. Але, залишайте коменти і ми їх обговоримо в наступному епізоді 😌

@ihorolkhovskyi429

11 ай бұрын

@@apprecode Тут є тонка межа. Одна справа - бізнес-логіка, інша - підтримка середовища де ця логіка крутиться. В ТЕОРІЇ бізнес-логіка має мати змогу прозоро переходити з одного середовища виконання на інше. Це і є слідування методології ДевОпс. Ідея в тому, що розробка - це створення нового (іноді принципово), а робота інфраструктурного інженера - перебирання готових "кубиків" технології, щоб забезпечити вимоги (програми, відмовостійкості, тощо), тобто саме "нового" там мало, скоріше "я знаю як треба" і намагання з готових кубиків скласти то саме ЩАСТЯ. І те, що кубики іноді доводиться точити не значить, що це щось принципово нове, бо результат вже відомий. Те, що ви знайшли новий спосіб зробити пензлик зі швабри і так само пофарбували паркан не робить вас художником. Тут може здатись, що я десь принижую роботу опсів в порівнянні з девами, це не так, насправді. У кожного своя роль. Парканів все ж більше ніж музеїв В якомусь сенсі дуже грубо, опси не займаються бізнес-логікою, але забезпечують її виконання. Для аналогії, в будівництві є архітектори, проектанти, будівники різних спеціалізацій і інженери з обслуговування. Це трохи різні люди.

Сінйор не знають пр AWS Budjet? Ви що серьозно? Це перше, що треба налаштовувати

CircleCi наразі мені найбільше подобається з усіх CI as a service. GitHub actions - do not repeat yourself погано реалізовано з коробки. Debug console для pipeline який валиться теж відсутній.

@apprecode

11 ай бұрын

Погоджуюся. Мені ще не подобається що самі по собі екшини це як NPM пакет. Ти його завантажуєш, білдаєш (часто це докефайл) і тоді він виконується. Хороший спосіб забрати в тебе побільше кредитних хвилин. Зате для пересічного стартап проєкту цього більш ніж достатньо. Для складних великих проєктів, краще користуватися старим добрим башом чи пайтоном.

48:43 Я слухаю на швидкості 1.5х і офігіваю, як Валєра. Чувак читає якесь закляття, щоб визвати Вельзевула. Він не розуміє всієї піраміди CI/CD. Працюю сисадміном понад 10 років. Таку діч з різних мов слухати важко. Середовища dev, test, stage i prod у великих компаніях створені для мінімізації кількості і ціни факапів. Це не бюрократія -- це мінімізація збитків. За падіння прода відповідає адміністратор СИСТЕМИ, а не девелопери (які мержать по 5 разів на день в гілку master). Саме тому СИСАДМІН ЗАЛИВАЄ РЕЛІЗ на прод після всіх тестів, а не девелопери. Замовнику пофіг на девелоперів -- замовник має на руках SLA, в якому серед виконавців є СИСАДМІН.

А давайте згенеруємо приклади як можна використати CI в системному адмініструванні. Є ідеї? Запуск скриптів по якомусь екшену?)

@Wzooff

11 ай бұрын

Легко. Тестуй анзібл плейбуки для розгортання того що адмініструється )

Думаю варто робити більш довгі випуски бо години мало

@apprecode

11 ай бұрын

кажуть що не можна))

Trunk based development підійде максимум для мініатюрних команд, а для великих команд ця методика породить лише хаос, для прикладу стане проблематично навіть поділитися своїм ще не готовим кодом з іншими членами команди щоб не споганити спільну гілку. Крім того пуш в мастер мав би бути в ручну одобрений, щоб гарантувати вищу якість коду, бо просто напросто хтось може забути написати важливий тест. Як на мене для серйозних проектів Trunk based development це безглуздя

Девопс, котрий запустив майнінг на AWS - ти мій герой, гаркнув в голосяндру

1:18:00 Кастомізація Дженкінса це великий "плюс". Всю кастомізацію можна задокументувати, а для Дженкінса її там не багато. Груві досить проста мова, я через годину гугління вже писав короткі сценарії. Не треба там створювати Франкенштейна. Кастомізація -- це не проблема старого ДевОпса, коли після звільнення роботодавець повинен знайти нового ДевОпса, який розбереться в Груві-коді. Нові розробники чомусь розбираються в java-коді попередників. А чим новий ДевОпс гірший за нового розробника на інтелектуальному рівні?

Транк бейсд схема требует более детального обсуждения. И имхо это был наиболее интересный топик за сегодня. Мало времени выделили на это.

По aws глобальні права повинні бути у архітектора а неу адміністратора.

Trunk Based Development is the only way of development 😄

То есть при описанном транк методе люди вечером и в пятницу ничего не мержат?)

@dmytrostriletskyi

11 ай бұрын

Це більше про антикрихкість, а не про TBD. Я запишу це собі в нотатки і ми зробимо це окремим невеликим топіком в якомусь епізоді, дякую!

@aleksandrsavvopulo4510

11 ай бұрын

@@dmytrostriletskyi спасибо) у меня будут и другие вопросы по этой теме. Мы уходим от гит флоу к транку, но немного в другом виде. И мне будет интересно подробнее изучить ваш подход.

Якась пісна херня, а не подкаст. Дівопс Інженер - верне від цього терміну, який просто сподобався ХР-ам з лінкд-іну, і понеслась.

Фу, назва не креативна, дизлайк

@unitysharp22

11 ай бұрын

А були... Були...

Як в айті відрізнити хлопця від дівчини ? Відповідь: в хлопців є борода. Без бороди не факт, що то хлопець 😅

Ну дуже погано. Хто починає подкаст з факапів? Ви тільки представились, 99.9% глядачів вас не знають - чому їм цікавим повинні бути історії ваших провалів зі старту? Ну продумайте хоч трошки драматургію… такі теми потрібно піднімати, коли вже всі вас ліпше дізнались. Далі: ваші історії зовсім не цікаві і не репрезентативні з точки зору висновків. Це просто скиглення штибу "подивіться, які ми(вони) рукожопи". Чому вони вчать: не робити паролі 1234qwerty та не майнити на АВС? Ну не обов’язково ж лизати сковорідку щоб зрозуміти що вона гаряча…