Bagaimana menerapkan pola server yang tidak dapat diubah tanpa kehilangan kemampuan untuk melakukan post-mortem?

Pola server yang tidak berubah adalah disiplin penggunaan yang mendukung reproduksibilitas penyebaran. Hal ini ditandai dengan fakta bahwa " server yang pernah digunakan, tidak pernah dimodifikasi, hanya diganti dengan contoh baru yang diperbarui " dan menerapkan disiplin ini membutuhkan otomatisasi penyebaran server. Otomatisasi ini memiliki banyak keuntungan operasional, salah satu yang paling penting adalah memungkinkan penggantian instance kegagalan yang cepat dan andal dalam suatu infrastruktur. Otomatisasi ini juga menyiratkan bahwa penyebaran server dijelaskan oleh artefak perangkat lunak berversi dan tunduk pada perbaikan berulang.

Aspek yang populer dari implementasi disiplin ini adalah penghapusan metode akses jarak jauh ke server setelah diluncurkan (terutama menghapus akses SSH). Menghapus akses jarak jauh adalah cara mudah untuk memastikan bahwa konfigurasi server cocok dengan konfigurasi yang disiapkan oleh otomatisasi penyebaran.

Namun, ketika menyelidiki penyebab kegagalan perangkat lunak dalam post-mortem , mengandalkan pemantauan terstruktur tidak selalu cukup dan akses jarak jauh ke mesin bisa diperlukan. Ini adalah situasi praktis yang umum bahwa pemantauan server tidak mencakup semua sumber kegagalan, atau pemantauan dapat terganggu oleh kegagalan server itu sendiri, yang kemungkinan akan menjadi kasus jika server kehabisan memori atau mencapai batas prosesnya.

Bagaimana menerapkan pola server yang tidak dapat diubah tanpa kehilangan kemampuan untuk melakukan post-mortem?

Pertama-tama, menghapus ssh pada server yang tidak dapat diubah tidak menjamin tidak akan ada perubahan, lebih dari itu karena seharusnya tidak perlu mengubah sesuatu yang Anda kurangi permukaan serangan dengan menghapus saluran akses jarak jauh.

Salah satu cara untuk menjaga semacam post-mortem adalah sentralisasi log. Ada banyak sekali metode untuk mencapainya, ELK stack, Splunk, syslog ...

Cara lain yang lebih kasar untuk mempertahankan post mortem untuk server yang tidak dapat diubah adalah dengan memiliki skrip pada proses shutdown (server yang tidak dapat diubah gagal akan ditutup dan yang baru berputar untuk menggantinya) untuk mengumpulkan dump inti dari program, sebuah dump memori dan mengirimkannya ke sistem jarak jauh untuk analisis bersama dengan sebagian besar log.

Keuntungan utama dari solusi ini adalah Anda hanya mendapatkan kembali informasi sistem yang gagal pada saat bermasalah, memungkinkan untuk mengumpulkan informasi yang lebih besar daripada mendapatkannya secara berkala.

Sulit untuk lebih spesifik tentang cara mencapai ini, setiap distribusi memiliki beberapa cara untuk mendapatkan sesuatu dan saya tidak punya contoh umum.

Fakta bahwa Anda tidak memiliki akses SSH tidak berarti tidak ada cara untuk mengakses mesin. Kemungkinan besar Anda akan menjalankannya di beberapa operator cloud, di mana Anda juga dapat melakukan hal berikut:

• ambil snapshot dari mesin. Anda bisa mengambil snapshot dari kotak sebelum menghancurkannya, untuk analisis selanjutnya.
• akses mesin melalui konsol. Anda mungkin perlu memiliki kata sandi root untuk ini, tetapi beberapa penyedia cloud dapat menyuntikkan kata sandi root acak untuk akses konsol kapan saja.

Ini pada dasarnya adalah akses "fisik" ke mesin Anda, dan akan tersedia bahkan jika Anda menghapus jenis akses lainnya. Anda dapat membatasi antarmuka ini juga.

Terlepas dari ini seperti yang dikatakan @Tensibai, hal terbaik yang harus dilakukan adalah memiliki pengaturan logging dan pemantauan yang tepat, jadi setiap kali Anda harus melakukan post mortem, ada cukup data yang tersedia untuk melakukannya.