Apa hal sysadmin yang harus diketahui oleh setiap programmer?

Sebagai seorang programmer, kita cenderung menerima sysadmin. Beberapa kali saya tanpa sysadmin yang baik benar-benar membuat saya menghargai apa yang Anda lakukan. Ketika kita berkelana ke lingkungan tanpa sysadmin, kata-kata bijak apa yang bisa Anda berikan kepada kami?

Saya akan mulai dengan:

1. Selalu memiliki semacam sistem cadangan. Bahkan lebih baik jika memiliki sejarah.
2. Pertimbangkan satu-satunya poin kegagalan dan bagaimana menghadapinya jika mereka gagal.
3. Bergantung pada jumlah komputer yang terlibat, mencari cara untuk membuat dan membuat gambar standar di seluruh komputer akan membuat hidup semua orang lebih mudah - tidak ada "ini bekerja pada saya" karena mereka memiliki program ini dan itu yang biasanya tidak diinstal.
4. Dokumentasikan semuanya, jika hanya karena Anda akan lupa bagaimana Anda mengatur sesuatu.
5. Mengikuti pembaruan keamanan.

<masukkan disclaimer pos besar di sini>

Beberapa di antaranya telah dikatakan sebelumnya, tetapi perlu diulang.

Dokumentasi:

• Dokumentasikan semuanya. Jika Anda tidak memilikinya, pasang wiki di bawah radar, tetapi pastikan Anda mencadangkannya. Mulailah dengan mengumpulkan fakta, dan suatu hari, gambaran besar akan terbentuk.

• Buat diagram untuk setiap potongan logis dan tetap perbarui. Saya tidak bisa menghitung berapa kali peta jaringan atau diagram cluster yang akurat menyelamatkan saya.

• Terus buat log untuk setiap sistem, meskipun itu hanya salin dan tempel perintah untuk cara membuatnya.

• Saat membangun sistem Anda, instal dan konfigurasikan aplikasi Anda, ujilah itu berfungsi dan lakukan benchmarking Anda. Sekarang, bersihkan cakramnya. Serius. 'dd' megabyte pertama dari bagian depan disk atau menjadikan kotak itu tidak bisa di-boot. Jam terus berdetak: buktikan dokumentasi Anda dapat membangunnya kembali dari awal (atau, lebih baik lagi, buktikan kolega Anda tidak lebih dari dokumentasi Anda). Ini akan membentuk setengah dari rencana Pemulihan Bencana Anda.

• Sekarang Anda memiliki paruh pertama rencana Pemulihan Bencana Anda, mendokumentasikan sisanya; cara mendapatkan status aplikasi Anda kembali (mengembalikan file dari tape, memuat kembali basis data dari dump), rincian vendor / dukungan, persyaratan jaringan, bagaimana dan di mana mendapatkan perangkat keras pengganti - apa pun yang dapat Anda pikirkan yang akan membantu sistem Anda dicadangkan.

Otomatisasi:

• Otomatiskan sebanyak yang Anda bisa. Jika Anda harus melakukan sesuatu tiga kali, pastikan yang kedua dihabiskan untuk mengembangkan otomasi Anda sehingga yang ketiga sepenuhnya otomatis. Jika Anda tidak dapat mengotomatiskannya, dokumentasikan. Ada suite otomatisasi di luar sana - lihat apakah Anda dapat membuatnya berfungsi untuk Anda.

Pemantauan:

• Instrumentasi aplikasi adalah emas murni. Mampu menonton transaksi yang melewati sistem membuat debugging dan pemecahan masalah jadi lebih mudah.

• Buat tes end-to-end yang membuktikan tidak hanya bahwa aplikasi itu hidup, tetapi benar-benar melakukan apa yang seharusnya. Poin adalah milik Anda jika dapat didongkrak ke dalam sistem pemantauan untuk tujuan peringatan. Ini melayani tugas ganda; selain membuktikan bahwa aplikasi itu berfungsi, itu membuat peningkatan sistem secara signifikan lebih mudah (memantau laporan sistem hijau, peningkatan berhasil, waktu untuk pulang).

• Patok tolok ukur, pantau, dan kumpulkan metrik untuk semua hal yang perlu dilakukan. Benchmark memberi tahu Anda kapan mengharapkan sesuatu akan mengeluarkan asap ajaib. Pemantauan memberi tahu Anda kapan ada. Metrik dan statistik memudahkan mendapatkan kit baru (dengan asap ajaib segar) melalui manajemen.

• Jika Anda tidak memiliki sistem pemantauan, terapkan satu. Poin bonus jika Anda benar-benar mendongkrak tes end-to-end di atasnya.

Keamanan:

• "chmod 777" (alias beri semua akses / hak istimewa) tidak pernah solusinya.

• Berlangganan prinsip 'paling sedikit'; jika tidak diinstal, disalin, atau hidup di disk, itu tidak dapat dikompromikan. OS dan instalasi perangkat lunak "Kitchen sink" mungkin membuat hidup lebih mudah selama fase pembangunan, tetapi Anda akhirnya membayar untuk itu.

• Ketahui untuk apa setiap port terbuka di server. Audit mereka sesering mungkin untuk memastikan tidak ada yang baru muncul.

• Jangan mencoba membersihkan server yang dikompromikan; itu perlu dibangun kembali dari awal. Membangun kembali ke server cadangan dengan media yang baru diunduh, mengembalikan hanya data dari cadangan (karena binari dapat dikompromikan) atau mengkloning host yang dikompromikan ke tempat yang terisolasi untuk analisis sehingga Anda dapat membangun kembali pada kit yang sama. Ada mimpi buruk hukum yang menyeluruh di sekitar ini, jadi berbuat salah di sisi pelestarian jika Anda perlu mencari jalan hukum. (Catatan: IANAL).

Perangkat keras:

• Jangan pernah berasumsi bahwa apa pun akan melakukan apa yang tertulis di kotak. Buktikan itu melakukan apa yang Anda butuhkan, kalau-kalau tidak. Anda akan mendapati diri Anda mengatakan "hampir berhasil" lebih sering daripada yang Anda harapkan.

• Jangan berhemat pada manajemen perangkat keras jarak jauh. Konsol serial dan manajemen lampu mati harus dianggap wajib. Poin bonus untuk strip daya yang dikendalikan dari jarak jauh untuk saat-saat ketika Anda kehabisan pilihan.

(Di samping: Ada dua cara untuk memperbaiki masalah pada jam 3 pagi, yang satu melibatkan kehangatan, bekerja dengan laptop melalui VPN di piyama Anda, yang lain melibatkan jaket tebal dan drive ke pusat data / kantor. Saya tahu yang mana yang saya lebih suka.)

Manajemen proyek:

• Libatkan orang-orang yang akan memelihara sistem sejak hari pertama siklus hidup proyek. Waktu tunggu pada kit dan waktu otak dapat dan akan mengejutkan, dan tidak ada keraguan mereka akan (harus?) Memiliki standar atau persyaratan yang akan menjadi ketergantungan proyek.

• Dokumentasi adalah bagian dari proyek. Anda tidak akan pernah punya waktu untuk menulis semuanya setelah proyek ditutup dan sistem telah pindah ke pemeliharaan, jadi pastikan itu dimasukkan sebagai upaya pada jadwal di awal.

• Terapkan keusangan yang direncanakan ke dalam proyek sejak hari pertama, dan mulailah siklus penyegaran enam bulan sebelum hari dimatikan yang Anda tentukan dalam dokumentasi proyek.

Server memiliki masa hidup yang ditentukan ketika mereka cocok untuk digunakan dalam produksi. Akhir dari masa hidup ini biasanya didefinisikan sebagai setiap kali vendor mulai mengenakan biaya lebih banyak dalam pemeliharaan tahunan daripada biaya untuk menyegarkan kit, atau sekitar tiga tahun, mana yang lebih pendek. Setelah waktu ini, mereka bagus untuk lingkungan pengembangan / pengujian, tetapi Anda tidak harus bergantung pada mereka untuk menjalankan bisnis. Meninjau kembali lingkungan pada 2 1/2 tahun memberi Anda banyak waktu untuk melompati manajemen yang diperlukan dan simpanan keuangan untuk pemesanan kit baru dan menerapkan migrasi yang lancar sebelum Anda mengirim kit lama ke vendor besar di angkasa.

Pengembangan:

• Pastikan pengembangan dan sistem pementasan Anda menyerupai produksi. VM atau teknik virtualisasi lainnya (zona, LDOM, vservers) membuat klon produksi dunia nyata-dalam-segala-akal-tetapi-kinerja mudah.

Cadangan

• Data yang tidak Anda cadangkan adalah data yang tidak Anda inginkan. Ini adalah hukum abadi. Pastikan kenyataan Anda cocok dengan ini.

• Cadangan lebih sulit daripada yang terlihat; beberapa file akan dibuka atau dikunci, sedangkan yang lain harus quiesced untuk memiliki harapan pemulihan, dan semua masalah ini perlu diatasi. Beberapa paket cadangan memiliki agen atau metode lain untuk menangani file yang terbuka / terkunci, paket lain tidak. Membuang basis data ke disk dan mencadangkannya dianggap sebagai satu bentuk "quiescing", tetapi itu bukan satu-satunya metode.

• Cadangan tidak berharga kecuali diuji. Setiap beberapa bulan, tarik kaset acak dari arsip, pastikan itu benar-benar memiliki data, dan datanya konsisten.

Dan yang paling penting...

Pilih mode kegagalan Anda, atau Murphy akan ... dan Murphy tidak bekerja sesuai jadwal Anda.

Desain untuk kegagalan, mendokumentasikan titik lemah yang dirancang masing-masing sistem, apa yang memicu mereka dan bagaimana memulihkan. Ini akan membuat perbedaan ketika ada yang tidak beres.

Jangan menganggap itu mudah. Saya tahu banyak programmer yang berpikir bahwa hanya karena mereka dapat mensetup IIS atau Apache di sana, mereka dapat menjalankan web farm. Memahami apa yang melibatkan pekerjaan dan melakukan penelitian dan perencanaan Anda, jangan hanya berpikir pekerjaan sysadmin adalah hal mudah yang dapat Anda lakukan dalam 10 menit untuk membuat aplikasi Anda dikerahkan.

• Sadarilah bahwa, baik atau buruk, banyak server dan / atau peralatan jaringan yang cenderung sangat mirip anak-anak dari keluarga kedua. Ini adalah bayi mereka. Mereka merawat mereka, membantu mereka ketika mereka sakit, dan mengawasi mereka dengan waspada untuk masalah. Ini tidak harus dengan cara ini, tapi setelah bertahun-tahun, itu sering . Ingatlah hal ini saat Anda menyampaikan kepada mereka kekhawatiran Anda tentang peralatan yang tidak berkinerja baik atau sesuai harapan. Dan jika Anda mendapatkan balasan yang tidak Anda mengerti, cobalah memfilternya melalui pandangan dunia ini.
• Berhubungan baik. Kedengarannya cheezy, tapi nilainya emas. Suatu hari, Anda akan membutuhkan bantuan khusus. Dan suatu hari, sysadmin itu akan dengan senang hati pergi keluar dari jalan mereka untuk membuat hidup sedikit lebih mudah bagi Anda, kali ini saja.
• Hubungan kerja itu berjalan dua arah. Jika sysadmin sangat sibuk, dan Anda bisa membuat hidup sedikit lebih mudah dengan menulis skrip atau program kecil, maka lakukanlah! Mereka akan menghargainya lebih dari yang Anda tahu.
• Sangat jelas. "Ini menyebalkan" tidak sejelas "memiliki koneksi jaringan yang terputus-putus agak mengganggu, ada kemungkinan Anda bisa melihatnya?"
• Jika menurut Anda aplikasi Anda akan berskala, tanyakan kepada admin sebelum menganggapnya akan. Mereka mungkin "melihat" sesuatu yang tidak Anda ketahui, atau tahu sesuatu tentang batas kinerja peralatan yang akan Anda gunakan.
• Jika aplikasi Anda perlu disetel, tetapi tampaknya itu bukan masalah kode, tanyakan baik-baik tentang kinerja server. Sysadmin merawat mesin-mesin mereka dengan perhatian penuh kasih dan tidak senang ketika mereka "sakit" atau "nakal". Bertanya dengan baik akan mengubah mesin yang sakit (atau memperbaikinya / diganti).
• (seperti yang disebutkan di tempat lain) mendokumentasikan pengaturan yang Anda gunakan, dan mengapa Anda menggunakannya. Hanya memiliki "set kotak centang X" atau "batalkan tanda tangan file konfigurasi Y" tidak membantu. Anda bisa mengatur opsi yang menghapus semua data Anda di reboot berikutnya untuk semua yang Anda tahu.
• Jika Anda tidak punya waktu untuk mendokumentasikan pengaturan di atas kertas, cobalah untuk mendokumentasikannya di sistem jika memungkinkan. Dengan file config, ini seharusnya hampir menjadi praktik standar - setiap perubahan pengaturan harus di-datestamp, dengan inisial, efek yang diharapkan dari pengaturan itu, dan alasan mengapa itu diubah (lihat poin sebelumnya). Kebiasaan kecil ini telah menghemat bacon saya lebih dari sekali selama waktu krisis. "Mengapa kita melakukan itu?" "Karena kita mengamanatkan kebijakan X, dan pengaturan Y memberi kita perilaku yang kita butuhkan untuk kebijakan X".
• Bir. Atau Cola. Atau bahkan Air. Minuman selalu disambut. Menjadi seorang sysadmin adalah pekerjaan yang haus.

Keamanan bukanlah renungan. Walaupun aplikasi yang diretas dapat membuat programmer terlihat tidak kompeten, itu (setidaknya) akhir pekan yang hilang dihabiskan untuk memverifikasi, membersihkan, dan / atau memulihkan dari cadangan untuk sysadmin.

Untuk itu, jangan memperlakukan cadangan sebagai kontrol versi. Mereka untuk pemulihan bencana, dan tidak benar-benar dirancang untuk mengembalikan kode Anda karena Anda lupa apa yang Anda ubah.

Dan hentikan menyalahkan Pembaruan Windows secara membuta karena kode Anda rusak. Saya tidak peduli itu berhasil, katakan padaku mengapa itu tidak berfungsi sekarang - maka kita bisa melihat kesalahan siapa itu.

Cara men-debug masalah jaringan dan menonton program Anda berjalan dengan alat sysadmin. Sebagai seorang programmer yang memulai dalam administrasi sistem, saya kagum dengan betapa impotennya banyak programmer menjadi jaringan "berhenti begitu saja."

• Wireshark , untuk menyaksikan kode Anda berjalan dalam mode kotak-hitam, paket demi paket
• Alat untuk terhubung langsung ke layanan jaringan:
  • Telnet, netcat, atau socat untuk koneksi biasa melalui TCP atau UDP
  • OpenSSL untuk hal yang sama dengan enkripsi (petunjuk: coba openssl s_client -connect target-host:portkapan saja), untuk menghubungkan secara manual ke layanan jaringan
• gali (dalam paket BIND 9) untuk debugging resolusi nama
• Mampu memberi tahu bagian mana dari tumpukan jaringan yang gagal berdasarkan waktu dan karakteristik koneksi yang gagal
• Kemungkinan HTTPFox dan / atau Firebug

Ketahui cara memecahkan masalah.

Sangat mudah untuk tidak bertanggung jawab (misalnya, jaringan Anda menyemprot komunikasi saya dengan database). Ini mungkin kesalahan jaringan, tetapi Anda harus memiliki log aplikasi dengan kesalahan yang, menggunakan Google atau SO, dapat mengungkapkan masalah dalam konfigurasi aplikasi.

Semua orang suka menyalahkan perangkat keras, OS, atau jaringan, jadi jika Anda berlatih sedikit lebih rajin, Anda akan membuat sysadmin menjadi orang yang bahagia. Karena, jika tidak ada yang lain, Anda mungkin dapat mengarahkan mereka ke arah yang spesifik tentang apa yang mungkin salah (berlawanan dengan mengatakan "jaringan Anda menyebalkan" atau sesuatu yang sama-sama membantu).

Dokumentasikan semua yang Anda bisa. Tidak dapat memberi tahu Anda berapa kali sysadmin terakhir berpikir akan lucu untuk tidak mendokumentasikan sesuatu untuk 'keamanan pekerjaan' atau seseorang yang hanya ingin masuk dan keluar. Sama seperti seorang programmer harus memberikan komentar yang baik, sysadmin harus mendokumentasikan. Diagram topologi juga bagus.

Rencana B.

Selalu miliki rencana pemulihan bencana saat merancang dan mengembangkan solusi. Kenali satu titik kegagalan yang dapat menyebabkan pemadaman.

Dokumentasi: tidak perlu menjadi gila, tetapi bagaimana aplikasi bekerja, diagram yang menunjukkan bagaimana bit cocok dan cara untuk menguji setiap komponen ketika semuanya salah. Sampel data dan outputnya bagus.

Persyaratan: modul apa yang diandalkannya? Versi? OS?

Pemantauan: idealnya pengembang akan memasukkan informasi pemantauan dan tes dengan aplikasi.

Bicara soal pengemasan, KEMASAN! Tidak ada yang lebih buruk daripada "penyebaran" yang berarti memeriksa revisi baru file dari VCS dan menyalinnya ke sekelompok server. Terlalu sering programmer tidak menghargai kompleksitas pengerahan perangkat lunak: ada alasan mengapa perangkat lunak versi, paket membentuk tulang punggung dari kebanyakan OS.

Jika seorang pengembang mendatangi saya dengan RPM yang diinstal pertama kali dengan dokumentasi yang ringkas, komprehensif, dan beberapa uji nagios, mereka akan menjadi sahabat baru saya.

Saya terkejut bahwa tidak ada dari 17 jawaban yang diberikan di sini sejauh ini termasuk apa pun tentang memastikan aplikasi Anda berjalan saat masuk sebagai pengguna standar.

Selain proses instalasi, aplikasi harus berjalan dengan baik ketika masuk dengan akun pengguna standar.

Backup Backup Backup .... Uji cadangan .... Selalu siap untuk memutar kembali

Ini mungkin berlaku hanya untuk pemrogram pemula, tetapi saya berurusan dengan beberapa hal pada setiap proyek dengan beberapa pemrogram.

1. "Ini bekerja pada mesin saya" tidak pernah merupakan pernyataan yang valid. Merupakan tanggung jawab programmer untuk membuat program instalasi untuk digunakan di server, atau setidaknya mendokumentasikan setiap koneksi dan dll serta add-in yang akan diperlukan di server.

2. (Saya sudah mendengar ini beberapa kali, jadi tolong jangan tertawa) Saya menjalankan exe di server dari mesin saya dan itu berfungsi. Tetapi, ketika saya menjalankannya di server (Citrix, Terminal Server, dll) tidak berfungsi. Tolong pahami dll dan ocx dan apa pun yang dibutuhkan oleh program Anda dan di mana serta bagaimana mereka terdaftar, dan bagaimana program Anda menggunakannya.

Ini mungkin tampak sederhana, tetapi saya selalu menghadapinya.

Brian

• berbicara dengan admin Anda baik secara formal maupun informal tentang apa yang Anda lakukan. Mereka biasanya akan tertarik dan dapat mengungkapkan dampak yang mungkin terjadi pada produksi sejak dini. Anda tidak harus setuju, tetapi membantu mengidentifikasi titik-titik masalah.
• Tidak, Anda tidak dapat memiliki seluruh server untuk diri sendiri ... Jika perlu, ini adalah keputusan politik, terlepas dari seberapa teknis suara itu. Jika Anda ingin bekerja dalam politik, silakan saja.
• Perangkat keras produksi seringkali terlihat berbeda dengan server pengembangan Anda, dan bahkan di dalam peternakan, spesifikasi pada mesin berbeda.
• Pelajari bagaimana produksi diatur, karena Anda kemungkinan tidak dapat mereplikasi di desktop Anda, melakukan ini mencegah Anda membuat asumsi yang buruk.
• Hanya karena Anda dapat men-cache item di memori tidak berarti Anda harus, tunggu bottleneck terlebih dahulu (dalam pengujian unit atau pengujian kinerja pra-produksi)
• jika Anda menempelkan data dalam basis data, pikirkan tentang bagaimana Anda dapat membagi data menjadi data hanya baca (yang dapat diskalakan secara horizontal) dan data baca-tulis (yang biasanya hanya berskala vertikal).
• jika Anda menempelkan data dalam basis data, harus benar-benar menjadi RDBMS? ada sistem pasangan kunci-nilai lain di luar sana yang skalanya lebih baik (netcache).
• jangan berpikir AJAX adalah solusi akhir semua, kelihatannya keren, tetapi membatasi kemungkinan pemantauan dan otomatisasi. Saya tidak mengatakan jangan menggunakannya, hanya berpikir dua kali.

OK ini sedikit mengomel tapi:

a) Saat melakukan pengkodean, asumsikan bahwa infrastruktur yang mendasarinya bisa gagal, dan tidak berasal dari senang-senang selalu ada di darat. Atau Google.

b) Kami mungkin tidak memiliki sumber daya untuk mengimplementasikan hal-hal seperti infrastruktur yang telah Anda baca, jadi santai saja pada kami ketika semuanya turun. Mungkin kita tahu apa yang perlu dilakukan, tetapi untuk alasan apa pun itu belum terjadi. Kami adalah mitra Anda!

c) Seperti kata jhs di atas, akan sangat membantu jika Anda memiliki pengetahuan yang lewat tentang alat untuk memecahkan masalah infrastruktur, seperti ping, traceroute (atau menggabungkan keduanya - mtr), menggali, dll. Poin bonus besar untuk mengetahui tentang Wireshark.

d) Jika Anda memprogram komputer, Anda benar-benar harus tahu bagaimana ia terhubung ke jaringan dan dasar-dasarnya seperti dapat mengurai output ipconfig / all atau ifconfig. Anda harus dapat mengaktifkan dan menjalankan koneksi internet dengan bantuan minimal.

Kalau tidak, saya pikir Avery cukup berhasil. Devs yang melakukan sysadmin kecil bernilai emas! Tetapi sama-sama, sysadmin yang memahami bagaimana para dev mengerjakan berbagai hal (termasuk versi, dll.) Sangat penting di zaman dan zaman ini.

Tampaknya ini sedang mengudara saat ini, saya telah memperhatikan lebih banyak diskusi tentang hubungan dev / ops di blog - lihat

Menjaga Twitter Berkicau

Partisi dan Peperangan

Tes Pertama dalam Operasi

Bahwa tidak ada satu kelompok atau fungsi yang 'lebih baik' dari yang lain dan tidak ada yang membutuhkan 'otak yang lebih besar' dari satu sama lain. Saya telah melihat kedua belah pihak mendapatkan semua prima-dona'ish di perusahaan lain - Anda semua berusaha untuk mencapai tujuan yang sama - fokus pada kesamaan ini dan bukan fakta bahwa Anda menggunakan alat yang berbeda.

Arsitek infrastruktur berubah menjadi programmer, mungkin ingin memutar kembali transaksi itu di masa depan :)

1. Saling berbicara, lebih awal dan sering. Tinjau desain dengan orang-orang yang akan mengelola infrastruktur yang akan digunakan aplikasi Anda (jika Anda tahu siapa yang akan menjadi).
2. Kehilangan data nol adalah mungkin, tetapi ini adalah tanggung jawab yang dibagikan oleh pengembang dan sysadmin. Sekali lagi, berbicara satu sama lain dapat membantu di sini.
3. Staf infrastruktur Anda seharusnya terlibat dalam menentukan persyaratan yang tidak fungsional.
4. Atur bir (saat pekerjaan selesai) dan pizza (saat kami sedang bekerja). Entah bagaimana, kehadiran makanan semacam itu berdampak pada kemampuan kita untuk membuat 32 kotak cpu kecil kita yang menyenangkan melakukan apa pun yang Anda inginkan :)

Sebagai seseorang yang telah menjadi admin sistem untuk pengembang, dan seorang pengembang sendiri, saran yang diberikan di sini bukan hanya emas, tetapi harus menjadi bagian dari dokumentasi perekrutan untuk pengembang baru untuk perusahaan di seluruh dunia.

Sesuatu yang belum saya lihat (belum) jelaskan adalah bahwa para pengembang benar-benar harus mengetahui produk yang akan mereka gunakan untuk membuat program yang mereka bayar. Jumlah waktu yang saya miliki untuk menjelaskan dan mengkonfigurasi server apache, gerhana dan instalasi Visual Studio, dan database pada mesin pengembang agak mengkhawatirkan.