Recommended
More Related Content
Similar to Playtika infra-30 mins to prod
Similar to Playtika infra-30 mins to prod (20)
Recently uploaded
Recently uploaded (20)
Playtika infra-30 mins to prod
- 1. 30 minutes to Prod
- 2. Vasyl Strutynskyi Hello R&D Director at Playtika
- 3. Intro
- 7. • Slotomania • Caesars Slots • House of Fun • Bingo Blitz • WSOP • Vegas Downtown Slots • Board Kings • Pirate Kings • Solitaire – Grand Harvest • Best Fiends • June's Journey • Tropicats • Bubble Island 2 • Diamond Dash • Jelly Splash About us
- 8. About us
- 9. ~3000 employees in 10 countries and 15 cities About us
- 10. 10 000 000+ daily active users About us
- 11. 6TB of data daily About us
- 12. 9 000 000 HTTP calls/min Slotomania
- 13. 205 micro services on Production Slotomania
- 14. Kafka cluster 158 000 messages/sec Slotomania
- 15. no downtime
- 16. Who we are and what we are doing
- 17. 99 people Infra
- 19. 11 games Infra
- 20. Infra Games
- 21. Infra domains User Service Payments Segmentation Rules Engine Bonuses BI services Contests Messaging Loyalty
- 22. Load per service 1 800 000 calls/min Loads
- 23. How to reach such results
- 24. 1. How to become predictable?
- 25. Keep commitment
- 26. Keep commitment •Only team is responsible to accept scope of the sprint
- 27. Keep commitment •Team has the right to push back any unclear user story
- 28. Keep commitment •Sprint Break •Sprint Commitment Update
- 29. 3 cycles of successful sprints in a row for All teams Challenge
- 30. 2. How to become transparent?
- 32. Infra.offsites
- 35. Infra.talks
- 37. All our dashboards and plans are open to everyone in the company
- 38. TV is powerful tool
- 39. 3. How to do more ?
- 40. Keep traction
- 41. Velocity
- 42. Velocity
- 43. Next metric to measure ?
- 44. # Deployments
- 45. 1 deployment
- 46. 1 deployment
- 47. 2 deployments
- 48. Ecosystem
- 49. organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations. — M. Conway Conway’s law
- 50. Triplets
- 51. Micro-teams Microservices Org correlates with Arch
- 55. 30 270 0 50 100 150 200 250 300 3 years ago Today Deployments # / month Deployments Deployments
- 56. 4. How to become faster?
- 57. As Small As Possible As Fast As Possible As Often As Possible Faster …
- 58. Pipeline evolution 1001h – 3d
- 59. Pipeline evolution 1h – 3d 3-10
- 61. No approvals to deploy Faster…
- 62. 3000 27 0 500 1000 1500 2000 2500 3000 3500 3 years ago Today Deployment time (min) deployment time (min) Time to Prod
- 63. 5. How to bring better quality?
- 64. Deployment is not end of the life – it is beginning of the life Start of the live
- 66. Quality Gate
- 67. PI monthly review Monthly production incident review
- 68. For every single PI – Prevention actions Prevention actions
- 69. 21 days in a row without PI Challenges
- 70. 24 days in a row without PI with 200+ deployments Challenges - Done
- 71. Challenges
- 72. 10 1.3 0 2 4 6 8 10 12 3 years ago Today ratio % ratio % PI / Deployments ratio
- 73. Other practices
- 77. Takeaways
- 78. Takeaways
- 79. Takeaways •Small teams, as small as possible •Team identification •Discipline in Agile •Atomic pull request •Deploy as often as possible •Continuously optimize your pipeline •Set challenges
- 82. Production Hello
Editor's Notes
- Доброго дня, мене звати Василь Струтинський. Я є РнД Директором Інфра департаменту в компанія Плейтика. Розпочав ІТ кар’єру в 2003 році як С++ розробник, будучи студентом 3го курсу факультету кібернетики університету Шевенка. Люблю спорт, біг, та лижі.
- Хочу вам розказати цікаві речі, зокрема інженерні практики про наш департамент в компанії Плейтика. Давайте спочатку познайомимся з компанією.
- Це наша команда Хто знає, що це за команда? Так, саме так - це футбольний клуб Севілія. Ми були офіційним партнер футбольного клубу Sevilla 2018-2019
- Ось так ми радіємо нашим перемогам
- А стільки у нас клієнтів Так, ми також є офіційним партнером of хокейного клубу Montreal Canadiens І як ви розуміли ми любимо ігри, Ми любимо грати ігри, а також створювати їх
- Продуктова компанія, яка володіє 15 ігор в жанрах Соціальне казіно та Кежуал Зараз активно розвиваємо Кежуал напрямок
- Зараз компанія активно розриває Casual напрямок ігор За останні роки були проведені наступні покупки
- Близько 3000 співробітників в 10 країнах і 15 міст світу
- Наші ігри приваблють більше 10 млн користувачів щоденно. DAU (Slotomania avg. 1 016 000)
- Наша еко-ситсема обробляє 6 терабайт інформації щоденно. Playtika processes over 6TB of data daily.
- Одна з провідних ігор, Слотоманія, ігровий клієнт отримує навантаження в 9 млн запитів на хвилину
- На цій грі Слотоманія розгорнуто 205 мікросервісів.
- Кафка кластер дозволяє опрацьовувати 158 тис меседжів в секунду
- Це все працює без downtime У нас реалізовано Active-Active підхід на двох дата центрах, Active-Passive.
- Декілька цікавих фактів про Інфра департамент
- Кількість людей в департаменті 99 в чотирьох локаціях: Ізраїль, Бухарест, Вінниця і Київ
- Число мікро сервісів, які розробляє і підтримує Інфра Додати Пай чарт
- Наші сервіси розгорнуті для 11 ігор
- Ми підтримуємо і розвиваємо 11 незалежних ігор У кожної з яких окремий environment, кожній з яких ми надаємо підтримку 24/7
- Це наші сервісами, якими ми розроблюємо і надаємо підтримку 24/7. Отже наші сервіси забезпечують функціонал, який є основним і може бути використаний у будь якій грі незалежно від її жанру. Тому що кожній грі потрібен юзер, потрібна монетизація ітд. Loyalty (Total reward system)
- Максимальна навантаження на сервіс складає 1 млн 800 тис викликів на хвилину, На кластері одного сервіса.
- Розкажу вам історію як ми розвивались і як ми досягнули таких результатів?
- Одну з перших речей яку ми зрозуміли потрібно розвивати, це як стати передбачуваними для себе, наших партнерів та наших клієнтів. Перед тим як ми перейдемо в деталі, я задам таке питання, хто використовує скрам ? Ок, тобто якщо я буду використовуват таку англо термінологію як спрінт – а не цикл чи ривок, Велосіті – а не швидкість Stakeholders – а не зацікавлені сторони То ми з вами порозуміємось?
- Ми зрозуміли що базовою основою успішної роботи і співпраці є дотримання раніше оголошеного плану, а це в свою чергу означає просту річ – вміти тримати слово. Така собі проста річ. Доречі, це є базовою основою не тільки в ІТ галузі, а й в будь яких інших. Згадайте наскільки розчарованими ви є, коли ваші будівельники затримують ремонт на кухні на тиждень, потім ще на тиждень, потім на два. Правда? Ви трохи починаєте нервувати і злитись і спілкування з будівельниками стає красномовним. То чому ми здивовані, що наші колеги в ІТ галузі трошки зляться, коли ми переносимо реліз? Базою основою ( немає значення чи в Аджайлі чи ватерфлоу) - Навчитись тримати слово!
- У нашому випадку тільки команда приймає обєм роботи на спрінт і дає слово, що вона виконає. Нb менеджер, нb директор, нb Продакт овнер і навіть не СТО.
- Якщо сторі не зрозуміла для команди, команда має повне право відмовитись брати таку сторі в спрінт.
- Також ми ввели дві чудові золоті практики Зупинка Спрінта та Оновлення зобов’язання в спрінті Я більш ніж впевнений, що ви неодноразово зустрічались з такими речами, як ПО вирішив кардинально змінити ціль спрінта, тому що бізнес просить і давай запихувати це все в один спрінт. Ногами, руками , попою – всім чим можна, щей менеджер прибігає і каже – так так, бізнесу треба і дружньо завалюють роботи на команду на 200%. Далі все просто кінесь спрінта – робота , звісно , не зроблена, ПО уже забув що ви йому говорили і тільк розмахує руками. А ви демотивовані і так зі спрінта в спрінт. Ось вам вудочка – Спрінт Брейк! Другий випадок – це коли коли хтось захворів під час спрінта. Не заплановано. В такому випадку команда має право оновити обєм спрінта.
- Ми поставли собі виклик зробити всіми командами три цикли успішних спрінтів один за одним, а це більше 10ти команд.
- Одне з перших запитань яке виникло - Як стати більш прозоприми для бізнесу а бізнесу для нас, Інфри? Інфра десь там тисячі кілометрів не робить ніяких корисного функціоналу для кінцевих гравців, отже не зрозуміло чим займається. В протилежну сторону, приходить бізнес і просить якусь частинку функціонала, яка зовсім не зрозуміла інженерам. Такий стан речей демотивує обидві сторони
- Отже прозорість є необхідною складовою для успішної роботи. Знову ж таки не тільки в ІТ і не тільки в Аджайл підходах. Прозорість у всіх діях і роботі. Прозорість в обидва напрямки від технологій до бізнесу і від бізнесу до ваших команд. Люди хочуть розуміти чому вони роблять той чи інший функціонал. Друга сильна сторона прозорості полягає в тому, що Ми не приховуємо проблеми. Оскільки прихована проблема під столом чи під ковриком - завтра обовязково взірветься. Бум! І зачепить значно більше сторін ніж в початковому стані.
- Для цього ми ввели таку практику як щоквартальна велика зустріч цілого департаменту з нашими клієнтами та партнерами (стейкхолдерами) Спілкуємось з стейкхолдерами Бізнес Продакт Овнери розказують про результати реалізованих фіч і про плану де буде залучена Інфра в нових фічах Плануємо наступний квартал Вирішуємо надскладні задачі, які знаходяться на перетині багатьох департаментів
- Інженери вирішують серйозні питання в широкому колі за 30 хвилин, те що в звичному денному житті потребує тижні для синхронізації.
- Відкрита та жива розмова раз на місяць чи півтора Розмовляйте з людьми з якими працюєте Слухайте людей з якими працюєте Не бійтесь людей з якими працюєте. Не бійтесь доносити на таких розмовах не популярні речі. Це значно краще ніж закинути листа на 100 людей чи меседж в канал. Жодні месенджери та листування не замінять живого спілкування
- Святкуйте перемоги на таких зустрічах
- Всі наші борди відкриті для всіх, Плани відкриті для вісх
- Ми використовуємо телевізори по всьому офісу, де показуємо всі наші статистики, рекламуємо ті чи інші зміни в процесах, анонсуємо новини.
- Давайте підсумуємо перший розділ, ми з вами навчились тримати слово, що принесло повагу наших партнерів та повагу всередині колективу І ми навчились бути прозорими у всіх напрямка. Ці дві речі уже значно підвищили мотивацію наших колег. Ок, раз ми такі круті, що ми хочемо далі. Ми хочемо робити більше.
- Щоб якось розуміти що таке більше треба це якось міряти. Але що таке більше? Якою метрикою можна виміряти? І як знати що сьогоднішня величина дійсно краща за вчорашню?
- МИ вирішили, що ОК - ми починаємо з Велосіті, його найлегше міряти, і ця метрика є найлегше зрозумілою. Протягнули декілька кварталів з концентрацією на те що велосіті хоч на 1 відсоток, але повинно зростати в командах. Але ж поставте команді КПІ і вона знайде як його взламати Правда ж? Ще й такий легкий КПІ як велосіті. Провесті інфляцію сторі поінтів ще легше ніж провести інфляцію в українській економіці. (підняти вартість гречки з 22 грн до 38грн.) Тому після стабілізації і досягення хороших результатів наступним кроком було знайти нову метрику, яка значно ближче відображає виконаний обєм робіт.
- Ми зрозуміли, що велосіті – це класно, але ми вже виросли з нього. Потрібно рухатись дальше.
- Ми зрозуміли, що велосіті – це класно, але ми вже виросли з нього. Потрібно рухатись дальше. І звісно цією метрикою стали, як ви гадаєте що? Правильно – кількість рядків коду .
- Щоб краще зрозуміти що ми більше робимо … Ми відпустили велосіті і сказали, що хочемо зібльшити кількість деплойментів на прод. Навіщо ми вирішили робити більше деплойментів. Тому що збільшення інкременту на продакшин , За рахунок менших деплойментів менше ризик продакшин інцидентів.
- Якщо у вас є одна команда і оодин мікросервіс то ви можете робити 1 заливку в один відрізок часу
- Якщо у вас є одна команда і оодин мікросервіс то ви можете робити 1 заливку в один відрізок часу
- Якщо у вас є одна команда і оодин мікросервіс то ви можете робити 1 заливку в один відрізок часу
- В основі нашої екосистеми лежить мікросервісна архітектура. Звісно, зібльшення деплойментів являється далеко не єдиною причиною чому ми сповідуємо мікросервісний підхід. І так, у нас мікросервісна архіт на базі Spring Cloud
- Закон Конвея — «Організації, які проектують системи, обмежені дизайном, який копіює структуру комунікацій в цій організації.» названное в честь программиста Мелвина Конвея выразившего идею в 1967 году Ми технологічний департамент тому не структура і комунікації впливають на архітектуру, а навпаки архітектура впливає на орг структуру департаменту.
- Також зрозуміли додаткові переваги маленьких команд - маленькі команди дозволяють бути більш прогнозованими, трьом людям запланувати значно легше ніж 10тьом.
- Отже у нас є мікрокоманди разом з мікросервісами, які дозволяють робити більше деплойментів, а також бути більш прогнозованими.
- Маленька, мінімальна команда - це неймовірний діаманд, який потрібно уміти відшліфувати.
- Отримавши багато маленьких команд ми зіткнулись з проблемкою що почали називати команда 1, 2, 3, … 10 і важко зрозуміти хто є хто чим займається.
- Це привнесло ще цікавий сайд ефект – команди почали горидитись своїми іменами і слоганами, ми дали максимум свободи для вибору. Також ця ідентифікація допомогла розвинути овнершіп.
- На сьоггдні кількість деплойментів на продакшин 270+ в місяць Три роки назад Було 30 в місяць Отже ми зросли практично в 10 раз, кількість деплойментів продовжує зростати з місяць в місяць, майже при одній і тій же тім капасіті команди.
- Ми визначили що критичний шлях у нас лежить в деплойментах Фіча реалізовується за 3 дні , а 5-7 днів виходить на продакшин.
- Ми розвинули наступні парадигми якомога менший атомарний пакет якомога швидше його доставляти якомога частіше його доставляти
- Звідси ми пройшли настпуну еволюцію нашого пайплайна To be updated by Alex
- Звідси ми пройшли настпуну еволюцію нашого пайплайна To be updated by Alex
- Звідси ми пройшли настпуну еволюцію нашого пайплайна
- Ми забрали всі аппруви для заливки.
- На сьогодні ми можемо принести результат нашої роботи на продакшин за 30 хв 3 роки назад це було тиждень і більше
- Після того як відбувся деплоймент, команди займаються моніторингом сервісу та за допомогою SLS and NOC надають підтримку Для кожної компанії клієнт дуже важливий, тому працюємо над тим, щоб було менше продуктовий інцидентів Чим менше продуктових інцидентів, тим більш щасиливими ми є.
- Ніщо так мотивує людей робити якісний продукт як 24/7 саппорт ( а це всвою чергу прокидання посеред ночі) Люди самі зацікавлені писати якісний продукт, не потрібно їх заставляти покривати тестами.
- І розвинули ось таку Піраміду тестування. To be updated by Alex
- Запрошуємо весь департамент зі всіх локацій. І інженери, які були причетні до того чи іншого інцидента, розказують які причини привели. Які првентивні методи ми застосовуємо. Особлива увага також людському фактору.
- Заходи профілактики
- Ми посавили Виклик, щоб 21 день прожити без жодного інциденту на всіх наших 90 мікросервісах і на всіх іграх.
- Ми досягнули 24 дні, зробивши близько 200 заливок. Після цього ми обовязково святкуємо такі чудові результати.
- Щоб всі бачили, де знаходиться Виклик – обовязково візуалізуйте. Ми використовуємо наші ТВ для цього. Зараз нашим челенджом є 31 день без інцидентів на всіх іграх.
- Наш рейт щодо продакшин інцидентам / заливки складає 1.3% Було 10%
- Розвивайте і підтримуйте у людях проактивну поведінку. Відмічайте таких людей на зустрічах, показуйте хороший приклад. Проактивність приность якісний результат
- Мінімізація мікроменджмента. Ваша ціль - Самодостатні команди, які беруть на себе відповідальність.
- Користуйтесь впровадженням Викликів
- У нас є стенд при виході з дівчатами, підходьте там є наліпки, світера, та інші корисні речі, Підходьте беріть з собою
- Починайте з базових речей. Розмовляйте з командами – вони знають рішення Зупиняйтесь, видихайте і задавайте питання що дальше ми можемо робити краще Ставте Виклики, якщо хочете досягнути кращих результатів.
- І на останок, хочу порекомендувати вам одну книжку – Ціль, Еліаху Гольдрат і Джеф Кокс