Production Plan

Peentar Production Plan (2017)

Transcript

1. We will start at around 1:40 PM at maximum 2:00 PM Thanks!
2. Peentar production and maintenance plan rev1
4. Bukan plan yang itu, tentu saja lol Karena kalau yang itu namanya power plant.
5. Peentar production and maintenance plan rev1
6. Istilah di slida ini Tanyakan ke forum: Pada saat slida ini dipresentasikan “Rule”: Sebuah usulan aturan / gagasan / prosedur, yang terbuka untuk dijeda
7. PRODUCTION AND MAINTENACE Perancangan •Design Pengembangan •Development Pengujian •Testing Pengerahan •Deployment Produksi & Perawatan •Production
8. PRODUCTION AND MAINTENACE Perancangan •Design Pengembangan •Development Pengujian •Testing Pengerahan •Deployment Produksi & Perawatan •Production Dibahas dikit Fokus utama
9. Well, Kenapa Butuh Perawatan? Kan programnya sudah jalan! Di dunia ideal, ya. But shit happens.
10. Kenapa kita memantau programnya? Di staging sudah dipantau juga dan jalan! Di dunia ideal, ya. But shit happens.
11. Deployment Pengerahan (Deploy) Rilis (Release) Pemantauan Berkala (Monitoring) Hotfix (Jika dibutuhkan)
12. Deployment Ideal Pengerahan (Deploy) Rilis (Release) Pemantauan Berkala (Monitoring) Hotfix (Jika dibutuhkan) Bersantai di Pantai
13. Deployment Sangat Ideal Pengerahan (Deploy) Rilis (Release) Pemantauan Berkala (Monitoring) Bersantai di Pantai
14. Studi Kasus 1: Kursi Belum Jadi
15. Before Production RELEASE MANAGER Atau Deployment Engineer Atau Site Engineer DEVELOPER Atau (IoT/Mobile/Frontend/Backend) Software Engineer PRODUCT OWNER Atau Marketing Atau Product Manager
16. Before Production DEVELOPER Atau (IoT/Mobile/Frontend/Backend) Software Engineer PRODUCT OWNER Atau Marketing Atau Product Manager PROGRAMNYA BELUM JADI PAK Kemarin itu baru tampilannya saja kemudian itu simulasi JANJINYA KAN MINGGU INI Dan kita sudah membuat iklan terkait dengan ini
17. Before Production DEVELOPER Atau (IoT/Mobile/Frontend/Backend) Software Engineer TANYA RELEASE MANAGER DEH Kemarin itu baru tampilannya saja kemudian itu simulasi
18. Why ask Release Manager? Memangnya Developer gak bisa push ke git? Bisa kan? Kalau ada di git berarti belum tentu masuk rilis donk? Branch release?
19. Rule 1: Not Everybody have access to production! Anda tidak bisa ssh ke produksi Bagaimana kalau ada yang tidak sengaja mematikan proses dan semua koneksi drop? “Tapi saya akan berhati-hati...” Di dunia ideal Anda bisa berhati-hati. Kenyataannya, human error terjadi. Manusia bisa mengantuk dan bisa patah hati. Moodnya bisa turun tiba-tiba dan dia bisa kehilangan konsentrasi.
20. Rule 2: We should have release manager/engineer Release Manager/Engineer adalah path, lebih kepada manajemen. Release Engineer bisa juga tim contact person. Release Engineer menentukan (dan terkadang cherry pick) fitur apa yang akan dimasukkan ke produksi Release Manager memiliki akses ke produksi, bersama tim devops Tidak semua fitur akan dirilis Release Manager Tim produk sepakat: jika secara engineering tidak matang, rilis tidak dilakukan! Release Manager tidak dapat disalahkan dari fitur yang terlambat. Itu merupakan tanggung jawab developer mengapa tidak memenuhi standar rilis.
21. Rule 2: We should have release manager/engineer Release Manager/Engineer adalah path, lebih kepada manajemen. Release Engineer bisa juga tim contact person. Release Engineer menentukan (dan terkadang cherry pick) fitur apa yang akan dimasukkan ke produksi Release Manager memiliki akses ke produksi, bersama tim devops Tidak semua fitur akan dirilis Release Manager Tim produk sepakat: jika secara engineering tidak matang, rilis tidak dilakukan! Release Manager tidak dapat disalahkan dari fitur yang terlambat. Itu merupakan tanggung jawab developer mengapa tidak memenuhi standar rilis.
22. Ilustrasi: Kursi Belum Jadi Andai ada kursi belum jadi (PRODUCT) dan tukang kayu (DEVELOPER) bilang lemnya salah dan bisa malah merusak kursi (PRODUCT DEFECT / UNTESTED), apakah Anda (PRODUCT MANAGER) akan tetap menduduki kursi itu? “Tapi saya perlu kursi itu besok!” “Ya tapi kursinya belum jadi!” What would you do?
23. Rilis telat == risiko bisnis
24. Rule 3: 50% progress must be achieved in 50% time Saat dalam 50% waktu tidak recapai 50% progress, komunikasikan ke tim Product! KPI Developer bukanlah menyelesaikan secepat-cepatnya, tetapi menyelesaikan sebuah hal dengan tingkat kesulitan yang dirasa pantas dalam waktu yang telah dinegosiasikan.
25. To Discuss: What is Release Manager KPI? Release manager mengizinkan / melarang rilis sesuai standar yang akan dibuat (e.g.: unit test > 70%, changelog jelas, sudah smoke test dan negative test, etc.) KPI Release Manager adalah jika dia mengizinkan rilis yang tidak memenuhi standar, dan melarang rilis yang memenuhi standar rilis. Bug, etc, diserahkan ke developer dan pager duty (ditentukan kemudian) Karena Release Manager tidak bertanggung jawab atas kode yang hidup di produksi.
26. Can & Can’t: Release Engineer, Product Manager, Developer Aspek Dev RE PM Mengatur Jadwal Rilis NO NO YES Mengizinkan Rilis NO YES NO Melakukan Rilis YES (izin dari RE) YES NO Memperbaiki bug YES YES (hanya jika RE merangkap dev) NO Menentukan fitur yang perlu dirilis NO NO YES
27. Studi Kasus 2: Kursinya Akhirnya Jadi! tapi rusak saat diantar
28. Transition to Production aka. deployment RELEASE MANAGER Atau Deployment Engineer Atau Site Engineer DEVELOPER Atau (IoT/Mobile/Frontend/Backend) Software Engineer PRODUCT OWNER Atau Marketing Atau Product Manager
29. Transition to Production aka. deployment RELEASE MANAGER Atau Deployment Engineer Atau Site Engineer DEVELOPER Atau (IoT/Mobile/Frontend/Backend) Software Engineer KODENYA SIAP RILIS PAK Dan sudah lulus tes!
30. Transition to Production aka. deployment RELEASE MANAGER Atau Deployment Engineer Atau Site Engineer KAMU NGUBAH APA SAJA? Dan impactnya ke modul apa saja?
31. Rule 4: Write Changelog! What? • Apa yang dirubah? Affects/Severity? • Mempengaruhi modul apa saja? • Jenis perubahan? Reference • Perintah kerja / post mortem: Task Phab / Story / FSD / ?
32. Rule 4: Write Changelog! Jika nanti setelah rilis ada masalah, kita hanya batasi masalah ke yang berubah saja Tapi tetap ingat dependency graph modul! Apa yang tidak Anda ubah berpotensi merusak jika ada dependency ke sana. E.g. A butuh B. Anda mengubah B. A berpotensi rusak.
33. https://support.apple.com/en-us/HT207482
34. https://support.apple.com/en-us/HT207482
37. https://github.com/Leaflet/Leaflet/blob/master/CHANGELOG.md
38. Transition to Production aka. deployment RELEASE MANAGER Atau Deployment Engineer Atau Site Engineer
39. Transition to Production aka. deployment RELEASE MANAGER Atau Deployment Engineer Atau Site Engineer SIP. RILIS DEH, TINGGAL KLIK DI JENKINS
40. Rule 5: There should be only one and single way to release and hotfix Rilis tak boleh sulit. Harus ada 1 cara yang jelas. Umumnya, rilis menggunakan 1 tombol di CI (Jenkins/Go/etc) atau menggunakan Hubot, atau menggunakan Ansible, atau Chef.
42. To Discuss: When to Release? Tiap akhir sprint? Setelah sprint review? Ingat, semua kode langsung alive di staging. Sprint review menampilkan progres dari staging, bukan production. Rilis di hari jumat selalu nightmare. Kalo ada masalah, begadang! Rilis pagi vs malam: Malam traffic sepi, tapi prone to error kalau mengantuk / terjadi apa-apa. Pagi / siang hanya untuk team yang mature (e.g.: unit test >80%), karena kalo ada masalah, digebukin customer.
43. To Discuss: Who Release? Tiap mau release, tentukan siapa yang akan merilis. Di-rolling saja. Yang merilis belum tentu release manager. Release manager memberikan izin dan prosedur rilis. Release manager TIDAK bertanggung jawab atas kerusakan karena rilis.
44. Things may go wrong! “Di staging jalan kok!” KENAPA ADA USER YANG MELAKUKAN ITU Disknya kok penuh LOL MEMORY LEAK
45. Studi Kasus 3: Pakai Kursinya
46. 3A Make Agreement: Pager Duty
47. Rule 6: There should be joyful pager duty Pager duty adalah orang-orang yang siap menangani masalah ketika ada masalah di produksi Pager duty HANYA 1 minggu dalam 3 bulan. (Direkomendasikan agar tidak mengganggu hidup / tidak membuat stres)
48. https://news.ycombinator.com/item?id=9010865
49. To Discuss: What if Paged Can’t solve problem? Jika ada yang di-page tapi tidak bisa menyelesaikan masalah, mungkin karena masalahnya terlalu berat, atau domain masalahnya berbeda sekali. Pertimbangkan untuk mengizinkan orang-orang bekerja cross-module (mengerjakan modul yang berbeda) agar ini tidak ditemukan.
50. 3B When Things Go Wrong: Workflow
51. When Things Go Wrong… Alerting •User/sistem memberitahu ada masalah urgent Pager •Yang saat itu terkena page harus menyelesaikan masalahnya Selesaikan •Jika tidak bisa, eskalasi. •Libatkan orang sesedikit mungkin, tapi tetap verbose Tulis Post Mortem •Dokumentasikan masalahnya dengan baik
52. Rule 7: If You Can, Don’t Hotfix. Semisal kita bias login dengan Google+ dan Facebook, tiba-tiba Facebook tidak dapat login. Hanya
53. Rule 8: Make ETA for solving problem Semisal kita bias login dengan Google+ dan Facebook, tiba-tiba Facebook tidak dapat login. Hanya
54. Rule 9: Debating Only for Maximum of 5% Solving Time “Waktu berdebat harus lebih singkat daripada waktu menyelesaikan masalah.”
55. Rule 10: Do Minimal Change Apa yang Anda lihat bekerja saat ini, belum tentu bekerja nanti. Pengubahan Anda dapat merusak modul lain. Saat melakukan hotfix, pastikan lakukan perubahan tersedikit
56. Rule 11: Fix and Do Post Mortem Later Saat ada masalah terjadi, fokus kepada menyelesaikan masalahnya. Mungkin Anda akan melihat kode yang jelek dan bergumam WTF siapa yang nulis ini. That’s fine, tetapi jangan lupa setiap downtime adalah kerugian. Btw, Amazon rugi 794 juta rupiah per downtime per menitnya (2013). http://www.forbes.com/sites/kellyclay/2013/08/19/amazon- com-goes-down-loses-66240-per-minute/#16fff62f3c2a
57. Menulis Post Mortem Masalah • Apa masalahnya? Solusi • Apa yang dilakukan sehingga masalahnya selesai? Penyebab • Kenapa masalah itu bisa terjadi? Mitigasi • Bagaimana agar ini tidak terjadi lagi? • Andai terjadi lagi, bagaimana agar dapat dilakukan dengan cepat?
61. Term: Hotfix
62. To Discuss: Hotfix or change? PO harus memiliki kebijaksanaan membedakan hotfix dan fitur. Hotfix merupakan perubahan yang dilakukan untuk mengatasi masalah yang tadinya tidak muncul di production. Semakin sedikit semakin baik. Hotfix != request yang berubah di tengah. Release Manager tetap berperan di sini. Release Manager tidak perlu mengawasi hotfix apa yang masuk, tetapi Release Manager perlu memberikan acuan hotfix apa yang boleh masuk.
63. 3C Trivia! Let’s Simulate!
64. Let’s Simulate! Mufid akan bertindak sebagai Release Manager. Karena di sini banyak engineer backend dan frontend, jadi skenario dipilih untuk masalah BE dan FE. Dibutuhkan setidaknya: - 2 orang pager duty (harus punya motor). Disarankan backend dan - 1 orang untuk eskalasi - 1 orang utusan rilis Siapapun dapat merangkap apapun.
65. Let’s Simulate! Git clone https://git.heroku.com/bajupro.git Username: hijacking.mupit+waza@gmail.com Password: ae12cdf3-0ce2-4f88-bcab-c0ff1b304771 Source code
66. Was that fun? Release should be fun. Seriously. You deploy new feature. You will be recognized. And you can proudly say to your spouse, “Hi dear, i make this.” Also of course you can impress your next employer with this :p
67. Rule 12: Chaos Monkey, or similar Chaos monkey adalah sebuah program yang ditulis oleh Netflix, yang sengaja melakukan kerusakan di production. Kenapa? Karena Netflix memiliki sistem yang self- healing. Kita bisa lakukan hal serupa. Bayangkan fire- drilling https://www.youtube.com/watch?v=UuTowptYlrM CATATAN: INI TARUH AKHUIR SAJA SETELAH SIMULASI
68. To Discuss: Don’t Be Afraid To Release Feature toggling keharusan. Merilis fitur yang belum jadi? PROS: Membuktikan bahwa fitur yang baru tidak merusak fitur yang lama CONS: Fiturnya belum jalan
69. Thanks!
71. Next Peentalk Estu Fardhani “Development pipelining & culture”
72. DEVELOPMENT CULTURE Perancangan •Design Pengembangan •Development Pengujian •Testing Pengerahan •Deployment Produksi & Perawatan •Production On Estu On Estu On Estu
73. Next on Next Peentalk Hanif Ibadurrahman “DESIGNVERSE1”