Veteran DevOps, Chris Bytaert, yang memelopori DevOpsDays, membagikan pengalamannya dan temuannya akan mengejutkan Anda.
Sepuluh tahun yang lalu, kami tiba-tiba melakukan perjalanan. Kami mempertemukan beberapa teman baik kami di Ghent, Belgia untuk membahas pengalaman komputasi awan Agile, open-source, dan awal. Pada tahun 2009, John Allspoe dan Paul Hammond memberi ceramah di Velocity pada "10 + Penyebaran Hari: Dev dan Ops Kolaborasi di Flickr" (dan itu worth watching). Setelah melihat pembicaraan ini, Patrick Debois memutuskan untuk mendirikan DevOpsDays.
Benarkah dunia DevOps telah banyak berubah selama 10 tahun ini? Saya telah menghadiri acara DevOpsDays sejak dimulainya konferensi, dan selama waktu ini saya telah mengumpulkan pengalaman yang signifikan. Dalam posting ini, saya akan membagikan 10 tutorial yang mungkin juga bisa membantu Anda.
1. Tidak ada yang namanya insinyur DevOps
Banyak tim memiliki seseorang dengan gelar DevOps Engineer, dan tidak semua spesialis menyukai gelar ini. Nama profesi ini memberikan kesan palsu bahwa DevOps adalah pekerjaan yang bisa dilakukan oleh satu orang. Lebih sering daripada tidak, seorang insinyur DevOps adalah seorang insinyur Linux yang, dengan sedikit keberuntungan, dapat memecahkan masalah otomatisasi. Ketika perekrut mulai mencari insinyur DevOps, pencari kerja harus menanyakan pertanyaan yang tepat kepada diri mereka sendiri: “Apa yang sebenarnya diinginkan perusahaan dari pencari kerja? Apakah mereka mencari insinyur perakitan? Senora yang mengerti persyaratan non-fungsional? Seorang spesialis di departemen operasi yang mampu menangani otomatisasi atau orang lain? " Paling sering, perusahaan mencari spesialis yang akan mengalihkan perhatian karyawan lainnya dari tidak memenuhi prinsip dan persyaratan praktis Agile.
Dalam organisasi dengan departemen DevOps yang besar, biasanya, tidak ada yang terlibat dalam DevOps. Kata "DevOps" hanya berbicara tentang pemisahan dari anggota tim lainnya, dan pelamar bisa mendapatkan gaji yang bagus dan mempelajari keterampilan baru di tempat kerja, tetapi dia tidak akan "melakukan DevOps".
2. Tim DevOps tidak ada
Kami telah sering mengatakan di masa lalu bahwa tujuan DevOps adalah menghilangkan kebingungan di antara tim yang berbeda. Secara khusus, antara pengembang dan karyawan departemen operasional. Namun, baru-baru ini kami menemukan fenomena baru - munculnya banyak tim DevOps.
Membangun tim DevOps terdengar seperti praktik baru, tetapi ada kontradiksi yang jelas di sini. Di satu organisasi, tim ini akan menangani alat pengembangan, di organisasi lain, ini secara harfiah merupakan dinding antara tim pengembangan dan spesialis operasi. Masalahnya, tembok ini menciptakan kebingungan, frustrasi, dan mengurangi tingkat interaksi yang berguna. Tim yang disebut "DevOps" paling baik memecahkan berbagai masalah dan memiliki tanggung jawab atas layanan tempat mereka bekerja. Biasanya tim profesional memilih untuk tidak menggunakan kata "DevOps" di nama mereka.
Menurut pengalaman saya, memiliki kata "DevOps" di nama tim kemungkinan akan menghalangi pencapaian hasil yang diinginkan.
3. Proyek DevOps tidak ada
Semua proyek terbatas. Anda mengembangkan, menerapkan solusi Anda, dan melanjutkan. Juga, selama 10 tahun terakhir, telah ada pembicaraan bahwa DevOps adalah peningkatan berkelanjutan, dan peningkatan berkelanjutan tidak ada habisnya. Pada gilirannya, hasil dari proyek Anda adalah layanan yang berjalan lama, dan layanan tersebut menyiratkan urutan "Pengembangan -> Penerapan -> Dukungan kesehatan"
Hanya setelah kami melihat layanan di luar proyek, kami dapat melihat aspek yang mudah dilupakan: persyaratan non-fungsional. Persyaratan non-fungsional mencakup fungsionalitas yang tidak sesuai dengan perilaku tertentu. Persyaratan ini juga menentukan penilaian kami terhadap kinerja sistem. Persyaratan ini sering kali mencakup aspek yang diklasifikasikan sebagai DevOps: keandalan, kegunaan, pemeliharaan, dan skalabilitas. Semua karakteristik ini penting untuk mencapai hasil bisnis.
Saat mengerjakan proyek jangka pendek, ada risiko Anda tidak akan cukup memperhatikan pekerjaan ini. Ketika Anda melanjutkan ke proyek berikutnya, Anda tidak akan lagi memikirkan persyaratan non-fungsional dari yang sebelumnya, karena Anda akan mengambil tantangan baru, dan masalah lainnya tidak lagi mengganggu Anda. Pada gilirannya, ketika mengelola layanan, Anda benar-benar tenggelam dalam pekerjaan, dan merupakan kepentingan terbaik Anda untuk memoles semuanya sedemikian rupa sehingga semuanya berjalan lancar.
4. Alat DevOps tidak ada
Sementara banyak vendor akan mencoba menjual berbagai alat kepada Anda, termasuk salah satu yang akan menyelesaikan semua masalah Anda, DevOps bukanlah tentang alat. DevOps adalah tentang orang-orang dan interaksi mereka. Beberapa alat sangat membantu orang berkolaborasi. Seringkali, alat dapat membantu orang-orang dari latar belakang berbeda berbagi terminologi dan ekosistem yang sama. Namun sering kali, alat menghalangi komunikasi yang efektif.
Budaya berbasis alat dapat mengisolasi orang daripada membantu mereka berinteraksi. Faktanya adalah orang menjadi terobsesi dengan toolchain mereka dan menjauh dari mereka yang tidak menggunakannya. Sementara alat tertentu bisa sangat berguna dari sudut pandang teknis, sejumlah alat baru (secara konvensional disebut sebagai DevOps) telah memperlebar celah di antara kelompok yang berbeda. Misalnya, saya sering mendengar ungkapan “ini berfungsi di wadah saya”. Pengembang menggunakan frasa ini untuk menunjukkan bahwa pekerjaan "mereka" telah selesai. Container itu sendiri tidak memecahkan masalah interoperabilitas yang terkait dengan menjalankan aplikasi secara efisien. Kita tidak bisa membiarkan alat menjauhkan kita dari satu sama lain.
5. Tidak ada sertifikasi di DevOps
Tidak ada tes pilihan ganda yang dapat memastikan bahwa Anda mampu berinteraksi secara efektif dengan rekan kerja. Organisasi yang menawarkan sertifikasi mungkin memiliki keahlian teknis yang luar biasa (dan bahkan komunikasi yang efektif), tetapi sertifikasi tidak dapat menunjukkan bahwa seseorang ahli dalam DevOps.
Sayangnya, tim manajemen membutuhkan sertifikasi di area yang sulit untuk disertifikasi. Pelajari perangkat lunak dan perangkat keras favorit Anda, dan jelajahi cloud. Belajar di universitas lokal, baca buku-buku yang darinya Anda dapat belajar banyak, khususnya, buku-buku oleh Deming , Forsgren , Humble dan banyak lainnya... Tapi jangan berharap menjadi yang terbaik di DevOps setelah Anda mendapatkan sertifikasi. Berinteraksi dengan rekan kerja jauh lebih penting.
6. Pipeline DevOps tidak ada
"Apakah DevOps sudah berfungsi?" "Pipeline DevOps berfungsi." "Pipa DevOps rusak." Setiap kali saya mendengar pernyataan ini, saya terkejut bahwa kami menemukan terminologi ini. Apakah kami mengubah merek pipeline penerapan, atau apakah di beberapa perusahaan tim DevOps sedang mengerjakan infrastruktur ini? Atau mungkin karena pengembang menelepon tim operasi jika pipa rusak?
Meskipun teknologi CI / CD sangat penting, saya skeptis tentang penggunaan istilah "pipeline DevOps". Jika pipeline pengembangan rusak, maka tim operasi yang harus disalahkan. Pengembang tidak memikirkan pipeline saat mereka menulis pengujian. Konsepnya sendiri juga menyesatkan. Pipeline dibuat untuk setiap layanan atau aplikasi secara terpisah, bukan di seluruh domain DevOps. Dengan membuat pipeline generik, kami berisiko meningkatkan kesenjangan antar tim, dan ini sama sekali bukan tujuan DevOps.
Saya merekomendasikan menggunakan teknik yang telah saya lihat di ratusan organisasi di seluruh dunia: panggil setiap pipeline individu sebagai pipeline Aplikasi X. Terminologi ini akan memudahkan untuk mengetahui aplikasi mana yang mengalami masalah saat menguji, menerapkan, atau mengupgrade. Kami juga akan mengetahui tim mana yang akan mengerjakan perbaikan di Lampiran X (mungkin dengan bantuan teman dari tim operasi).
7. DevOps tidak memiliki standar
Yang paling sulit dari ribuan cerita DevOps adalah standardisasi. Dengan cara yang sama seperti kami tidak dapat mensertifikasi orang, tidak ada standar universal di DevOps. Setiap organisasi memiliki jalurnya sendiri, dan jalur ini bisa sangat berbeda. Tidak ada resep ajaib yang mencantumkan alat dan menjelaskan metode untuk membuat alur otomatisasi yang tiba-tiba akan menjadi DevOps di organisasi Anda.
Standar dalam DevOps berarti Anda menerapkan metodologi tertentu yang akan memungkinkan organisasi Anda untuk mulai berkolaborasi dan menjauh dari politik kantor. Itu juga harus meningkatkan kualitas kerja, meningkatkan semangat dan memungkinkan Anda mencapai hasil yang lebih baik dengan lebih sedikit gangguan.
DevOps harus dipahami sebagai seperangkat praktik yang mirip dengan metodologiITIL . Ingatlah bahwa L di ITIL adalah singkatan dari Library. Dan pustaka ini harus diambil bukan sebagai panduan untuk bertindak, tetapi sebagai daftar praktik terbaik, yang darinya Anda perlu memilih yang paling sesuai untuk Anda. ITIL dibenci justru karena implementasi yang tidak berhasil, di mana perpustakaan digunakan tepat sebagai instruksi langkah demi langkah. Standardisasi di DevOps akan memberikan hasil yang sama.
8. Tidak ada yang namanya DevSecOps
Kami memulai DevOpsDays pada tahun 2009 dan konferensi ini terbuka untuk semua orang. Tentu saja, awalnya ini adalah acara untuk pengembang dan karyawan tim operasional, tetapi semua orang mendatangi kami: administrator database, penguji, analis bisnis, pemodal, dan, tentu saja, spesialis keamanan. Kembali pada tahun 2012, kami berbicara di pertemuan OWASP membicarakan tentang apa yang kami lakukan. Kami bercanda bahwa "S" di DevOps berarti keamanan, seperti "S" di HTTPS.
DevOps adalah tentang keamanan pada intinya. Saya telah menemukan bahwa prinsip CD paling cocok untuk tim keamanan. CD adalah persyaratan keamanan: Anda harus dapat menyebarkan kapan saja, ini akan memberi Anda kemampuan untuk menyebarkan dan menerapkan pembaruan yang diperlukan oleh bisnis atau masalah keamanan Anda.
Di satu sisi, menyedihkan bahwa kami harus mengeluarkan kata-kata untuk memasukkan orang-orang yang bertanggung jawab atas keamanan. Di sisi lain, ada baiknya kita membahas ini lagi. Pada dasarnya, tidak ada perbedaan antara DevSecOps dan DevOps. Keselamatan selalu menjadi bagian dari pengembangan dan operasi. Saya dapat menggunakan istilah DevSecOps untuk ini, tetapi lebih baik menggunakan istilah DevOps.
9. Anda tidak dapat mengambil dan beralih ke DevOps
Pernahkah Anda bertemu dengan perusahaan yang membuat pernyataan seperti “Kami sedang melakukan proyek DevOps pada kuartal keempat tahun ini, dan tahun depan kami akan pindah ke DevOps sepenuhnya”, yang benar-benar berhasil? Jadi saya belum bertemu.
Pengiriman perangkat lunak tidak pernah berhenti, teknologi selalu berubah, selalu membutuhkan dukungan, dan (idealnya) pendekatan dan sikap terhadap DevOps harus tetap sama. Setelah Anda menyempurnakan pendekatan pengiriman, Anda ingin meningkatkan lebih jauh. Bukan karena semua fungsionalitas aplikasi Anda telah diterapkan atau karena ekosistem tempatnya hidup telah berhenti berkembang. Anda pasti ingin terus berkembang karena kualitas pekerjaan Anda tumbuh secara eksponensial, dan pada saat yang sama kualitas hidup juga meningkat. DevOps akan terus berkembang bahkan setelah beberapa tugas mendapatkan status Selesai.
10. Ada yang namanya "Dev-oops"
Sayangnya, banyak orang yang tidak memahami pentingnya kolaborasi. Mereka membangun tembok di antara tim, percaya bahwa alat lebih penting daripada praktik, membutuhkan sertifikasi untuk segalanya dan semua orang. Mereka juga percaya bahwa kesembilan pernyataan sebelumnya tidak benar. Dan orang-orang ini akan selamanya berjuang untuk berhasil dalam apa yang saya sebut Dev-Ups.
DevOps adalah tentang alat berpikir dan pemisahan tim lebih penting daripada prinsip DevOps sejati yang dapat meningkatkan pekerjaan Anda. Mari berjuang untuk melakukan DevOps, bukan DevOops.
tujuan utamanya
Kami telah menjalankan DevOpsDays selama 10 tahun, dan selama waktu ini ribuan orang telah belajar banyak hal menarik dari satu sama lain dalam lingkungan yang mudah dan terbuka. Beberapa konsep yang menurut saya bertentangan dengan tujuan DevOps dan agile sangat populer. Fokus untuk mendapatkan layanan Anda untuk membantu perusahaan Anda dan jangan berhenti belajar. Dan ini bukan tentang menyalin alat dan menerapkannya di organisasi Anda. Ini tentang fokus pada peningkatan berkelanjutan dalam segala hal.
Pelajari lebih lanjut tentang cara mendapatkan profesi profil tinggi dari awal atau Naik Level dalam keterampilan dan gaji dengan mengikuti kursus online berbayar SkillFactory:
- Kursus DevOps (12 bulan)
Lebih banyak kursus
- - (8 )
- UX- (9 )
- Web- (7 )
- Machine Learning (12 )
- Data Science (12 )
- (9 )
- «Python -» (9 )