SRE dalam konteks

  • 10 menit

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, kita akan mempelajari beberapa riwayat di balik SRE dan hubungannya dengan praktik operasi lain yang mungkin familier untuk Anda. Ini akan meningkatkan presentase kesuksesan nantinya karena praktik tersebut akan lebih masuk akal jika memiliki konteks. Selain itu, saat teman-teman Anda bertanya "Apa perbedaan SRE dari ..." Anda akan siap menjawab.

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 (saat itu hanya tujuh teknisi perangkat lunak) dan menciptakan gagasan terkenal yang dia gambarkan sebagai “apa yang terjadi saat Anda meminta teknisi perangkat lunak untuk merancang fungsi operasi.” Sejarah di sini bermanfaat untuk dipahami karena membantu menjelaskan mengapa SRE dapat dirasa sebagai "rekayasa perangkat lunak" bagi orang-orang operasi yang menggunakannya 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 sejumlah 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 beberapa informasi yang baik untuk diketahui tentang DevOps, lihat https://docs.microsoft.com/azure/devops/learn/.

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 Azure DevOps masih dalam diskusi 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 keinginan 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). 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, Anda tidak perlu membuat keputusan mendadak.

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 adalah kumpulan operasi pemikiran yang berdampingan dan paling baik dalam kondisi tersebut.

Kini setelah kita melihat beberapa latar belakang SRE secara singkat, mari kita berpindah 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?