SRE dalam konteks

Selesai

Sebelum kita menjelajahi beberapa praktik yang terkait dengan SRE, ada baiknya untuk memberikan konteks pada beberapa ide yang baru saja kita pelajari di unit sebelumnya. Dalam unit singkat ini, kami mempelajari beberapa riwayat di balik SRE dan bagaimana hubungannya dengan praktik operasi lain yang mungkin Anda kenal. Pengetahuan ini mengatur kita untuk kesuksesan yang lebih besar nanti karena praktik-praktik tersebut lebih masuk akal dalam konteks. Juga, ketika teman-teman Anda bertanya "Bagaimana SRE berbeda dari ..." Anda memiliki jawaban yang siap.

Riwayat

Sejarah SRE yang sangat ringkas dimulai dengan asal-usulnya di Google pada tahun 2003. Ben Treynor, sekarang Treynor Sloss, mengambil alih kepemimpinan "Tim Produksi" Google (kemudian hanya tujuh insinyur perangkat lunak). Treynor menciptakan ide dan secara terkenal menggambarkannya sebagai "apa yang terjadi ketika Anda meminta teknisi perangkat lunak untuk merancang fungsi operasi." Sangat berguna untuk memahami riwayat ini karena membantu menjelaskan mengapa SRE dapat merasa sangat "rekayasa perangkat lunak" untuk mengoperasikan orang-orang yang memenuhinya untuk pertama kalinya. SRE telah mengadopsi nilai dan alat dari bidang itu seperti pentingnya pengodean dan sistem kontrol sumber sebagai alat mendasar. Implementasi Google SRE awal dan yang saat ini didokumentasikan dengan baik dalam dua buku mereka yang diterbitkan oleh O'Reilly (lihat unit Memulai).

Saat orang-orang dari Google meninggalkan perusahaan (dan orang-orang di perusahaan lebih banyak mendiskusikan tentang praktik mereka secara publik), SRE mulai menyebar ke lebih banyak organisasi di industri. Saat SRE menyebar ke organisasi baru, organisasi tersebut mengadopsi dan mengadaptasi prinsip dan praktik SRE agar sesuai dengan budaya lokal mereka. Proses ekspansi ini telah menghasilkan banyak implementasi SRE yang berbeda di lapangan.

DevOps dan SRE

Industri yang lebih luas menghadapi tantangan yang sama terkait penskalaan, kecepatan pengembangan vs. stabilitas operasional, dan masalah pengiriman perangkat lunak lainnya yang memunculkan pergerakan rekayasa keandalan situs. Upaya paralel untuk mengatasinya di luar Google (dan beberapa perusahaan yang lebih besar pada saat itu) menghasilkan DevOps.

Untuk mendapatkan banyak informasi bagus tentang DevOps, lihat pusat sumber daya DevOps.

Catatan

Penting untuk dicatat bahwa DevOps dan SRE adalah dua upaya paralel yang berbeda untuk mengatasi tantangan yang sama. SRE bukan langkah evolusioner setelah DevOps. SRE tidak dibuat untuk menjadi "masa depan DevOps".

Perbedaan SRE dan DevOps adalah subjek yang masih dalam diskusi yang cukup besar di lapangan. Ada beberapa perbedaan yang disepakati secara luas, termasuk:

  • SRE adalah disiplin teknik yang berfokus pada keandalan. DevOps adalah gerakan budaya yang muncul dari urge untuk memecah silo yang biasanya terkait dengan organisasi Pengembangan dan Operasi terpisah.
  • SRE dapat menjadi nama peran seperti dalam "Saya adalah perekayasa keandalan situs (SRE)", sedangkan DevOps tidak bisa melakukannya. Sesungguhnya, tidak seorang pun menggunakan "DevOps" sebagai pekerjaan.
  • SRE cenderung lebih preskriptif, sedangkan DevOps tidak demikian. Adopsi yang hampir universal dari integrasi berkelanjutan/pengiriman berkelanjutan, dan prinsip Agile adalah definisi terdekat dari Azure DevOps.

Dua praktik operasi, DevOps dan SRE, sama-sama tentang pemantauan/pengamatan dan otomatisasi (mungkin untuk alasan yang berbeda). Keyakinan ini adalah salah satu alasan mengapa seringkali lebih mudah untuk mengimpor praktik dan prinsip SRE ke dalam organisasi dengan praktik DevOps yang ada. Proses itu harus dilakukan dengan hati-hati dan niat yang baik. Ini juga dapat dan harus diimplementasikan secara bertahap, seseorang tidak perlu membuat sakelar tiba-tiba.

Peringatan

Menukar gelar untuk orang-orang dalam organisasi adalah strategi implementasi yang hampir tidak pernah berhasil. Ini tidak akan menghasilkan manfaat yang ditawarkan SRE. Lihat bagian Memulai di unit ini untuk beberapa saran yang lebih baik.

Kesimpulan

Unit singkat ini telah berusaha untuk menempatkan sejumlah kecil konteks untuk SRE dan DevOps. SRE dan DevOps paling baik dianggap sebagai sekolah pemikiran yang berdekatan dalam praktik operasi.

Sekarang setelah kita secara singkat melihat beberapa latar belakang di belakang SRE, mari kita pindah langsung ke beberapa prinsip intinya.

Uji pengetahuan Anda

1.

Mengingat asal-usul SRE, disiplin mana yang paling berdampak untuknya?

2.

Mana yang lebih dulu ada, DevOps atau SRE?

3.

Apakah SRE merupakan langkah evolusioner berikutnya dari DevOps?

4.

Apa saja dua praktik terbaik yang merupakan pusat dari devOps dan SRE?