Kunci otomatisasi bertahap: skrip do-nothing (2019)

• Di tim operasional, prosedur manual (toil) yang sulit dihilangkan sepenuhnya seperti perubahan infrastruktur atau provisioning akun masih tetap ada, dan semakin besar perusahaan, semakin banyak langkah serta pengecualiannya
• Setiap langkah tampak bisa diotomatisasi, tetapi jika hanya sebagian yang dijadikan skrip, jumlah alat satu tujuan akan bertambah dan pengguna tetap harus mengikuti dokumen prosedur yang panjang
• Skrip do-nothing tidak menjalankan pekerjaan nyata secara otomatis; alih-alih, skrip ini membungkus setiap langkah prosedur dalam fungsi lalu memberi instruksi kepada pengguna selangkah demi selangkah
• Pengguna jadi lebih kecil kemungkinannya kehilangan posisi saat ini atau melewati langkah, dan pengembang nantinya lebih mudah mengubah teks panduan pada langkah tertentu menjadi kode otomatisasi nyata
• Meskipun jumlah pekerjaan manual saat ini tidak langsung berkurang, pendekatan ini menurunkan biaya awal untuk memulai otomatisasi, sehingga toil dapat dihapus secara bertahap seiring waktu

---

Saat prosedur manual menjadi beban berat

• Setiap tim operasional masih memiliki prosedur manual yang belum berhasil diotomatisasi, dan toil sulit dihilangkan sepenuhnya
• Di perusahaan yang sedang tumbuh, prosedur seperti perubahan infrastruktur atau provisioning akun pengguna mudah menjadi pusat toil yang besar
• Prosedur provisioning akun pengguna dapat melalui beberapa langkah seperti berikut
  • Membuat pasangan kunci SSH pengguna
  • Commit kunci publik ke Git lalu push ke master
  • Menunggu pekerjaan build selesai
  • Memeriksa alamat email pengguna di direktori karyawan
  • Mengirimkan kunci privat kepada pengguna melalui 1Password
• Di lingkungan nyata, prosedur ini bisa bertambah hingga 20 langkah, atau Anda mungkin harus terus melacak percabangan dan kasus khusus selama proses berjalan
• Pekerjaan seperti ini menuntut banyak konsentrasi, tetapi lebih mirip mencentang satu kotak lagi daripada menyelesaikan masalah yang menarik, sehingga menjadi slog

Celah yang ditinggalkan otomatisasi parsial

• Slog tampak sebagai target yang bagus untuk diotomatisasi
  • Mudah membayangkan cara mengotomatisasi setiap langkah
  • Komputer dapat menjalankan instruksi lebih cepat dan lebih akurat daripada manusia
  • Kemungkinan terjadinya practical drift juga lebih rendah
• Masalahnya, otomatisasi slog sering terasa seperti semua atau tidak sama sekali
• Anda bisa membuat skrip yang hanya menangani 2 atau 5 langkah, tetapi kerepotan keseluruhan prosedur tetap tidak banyak berkurang
• Ketika skrip satu tujuan semakin banyak, konvensi dan perilaku yang diharapkan dari tiap alat menjadi berbeda-beda, dan pengguna tetap harus mengikuti dokumentasi untuk banyak langkah

Cara kerja skrip do-nothing

• Hampir semua slog dapat diubah menjadi skrip do-nothing
• Intinya adalah memasukkan instruksi slog ke dalam kode, lalu mengenkapsulasi setiap langkah sebagai satu fungsi
• Alur skrip contoh adalah sebagai berikut
  • CreateSSHKeypairStep menampilkan perintah ssh-keygen dan menunggu sampai pengguna menekan Enter
  • GitCommitStep menyalin kunci publik ke repositori Git lalu mengarahkan pengguna untuk menjalankan git commit, git push
  • WaitForBuildStep mengarahkan pengguna untuk menunggu hingga selesai pada URL pekerjaan build
  • RetrieveUserEmailStep mencari alamat email di direktori lalu menerimanya sebagai input dan menyimpannya ke context["email"]
  • SendPrivateKeyStep mengarahkan pengguna untuk membuat dokumen kunci privat di 1Password dan membagikannya kepada pengguna dengan email tersebut
• Skrip ini tidak benar-benar menjalankan langkah apa pun dalam prosedur; skrip hanya memberi instruksi kepada pengguna satu langkah demi satu langkah lalu menunggu penyelesaian manual

Jalur menuju otomatisasi

• Sekilas, skrip do-nothing mungkin terlihat seperti membuat dokumentasi makin sulit dibaca, tetapi sebenarnya justru membantu menjaga alur kerja dengan lebih aman
  • Pengguna menjadi lebih kecil kemungkinannya kehilangan jejak progres atau melewati langkah
  • Lebih mudah mempertahankan fokus dan menyelesaikan slog sampai akhir
  • Karena setiap langkah dipisahkan sebagai fungsi, teks pada langkah tertentu dapat diganti dengan kode tindakan nyata
  • Seiring waktu, akan muncul pustaka langkah yang dapat digunakan ulang, dan pekerjaan otomatisasi berikutnya menjadi lebih efisien
• Skrip do-nothing itu sendiri tidak mengurangi jumlah pekerjaan manual tim
• Nilai utamanya adalah menciptakan kondisi yang memudahkan memulai otomatisasi, sehingga tim dapat menghapus toil seiring waktu di atas fondasi itu

[GN⁺]

Pendapat di Hacker News

• Saya sangat menyukai pendekatan ini
  Secara keseluruhan, ini adalah cara lain untuk mendefinisikan antarmuka di sekitar sebuah proses. Proses itu bisa manual atau bisa diautomasi, tetapi antarmukanya dapat tetap sama. Karena itu, pendekatan ini cukup kuat saat mengautomasi langkah-langkahnya
  Terapkan saja dengan cara yang sama seperti pada sistem lain
  Dulu saya pernah mengisi Google Sheets secara manual lalu mengautomasi dengan skrip, dan juga pernah membuatnya otomatis mengambil dan memproses saat tiket Jira dibuat. Anda bisa mulai lebih cepat, mengautomasi hanya bagian yang paling menjengkelkan, dan tidak harus mengautomasi semuanya
  Efek samping dari skrip yang tidak melakukan apa-apa adalah kemungkinan besar ia benar-benar dipakai dibanding dokumentasi, sehingga bisa lebih sering tetap mutakhir

  • Menurut saya yang tidak terlalu rendah hati, jika proses dienkode secara bertahap ke dalam skrip seperti ini, yang terbentuk adalah sistem yang berpusat pada proses, bukan sistem yang menelan proses
    Saya setuju dengan daftar skrip untuk mengautomasi pekerjaan umum. Namun begitu skrip-skrip itu mulai dipanggil dari layanan operasional, terciptalah utang teknis besar bagi orang malang yang harus mengurai jejaring spageti itu
    Lebih jauh lagi, karena proses yang berpusat pada manusia telah mengodekan sistem, perubahan yang menguntungkan sistem perangkat lunak—misalnya memecah sistem menjadi komponen—menjadi tidak mungkin. Pada akhirnya, ekspansi bertahap menjadi cara untuk memasukkan lebih banyak hal ke dalam proses, dan itu menjadi siklus proliferasi mandiri yang terus menempel pada monolit skrip
  • Pendekatan lama adalah seperti ini: 1) tangkap proses saat ini apa adanya 2) buat proses itu lolos laugh test 3) buat agar bisa diautomasi
    Selama menjalankan 3 dan 4, proses digunakan berulang-ulang oleh sebanyak mungkin orang, lalu proses disesuaikan dengan penyalahgunaan yang terlihat di lapangan nyata
    4) automasi prosesnya
    Semua orang setuju dengan 1 dan 2, dan kebanyakan pada akhirnya juga ikut ke 4, tetapi jika melakukan 3, makin banyak orang yang meminta dan memahami 4
    Namun batasan pendekatan ini adalah: jika awal atau akhir proses bisa diautomasi, itu masih baik-baik saja; tetapi jika ada dua titik automasi yang terpisah seperti pulau di tengah proses, itu tidak lebih baik daripada alat command-line dengan prompt
  • Benar. Bagi saya ini juga menjadi kesempatan lain untuk memakai dan berbagi Jupyter notebooks
    Cukup jelaskan apa yang perlu dilakukan, lalu sediakan boilerplate atau contoh serta executable yang diparameterisasi
    Akan keren jika Notebooks dipakai sebagai sistem dokumentasi secara de facto. Namun, ia terlalu berat untuk dijadikan lapisan di atas cloud SaaS seperti Confluence, dan dalam bentuknya sekarang juga menyisakan terlalu banyak celah untuk masalah seperti eskalasi hak akses
  • Saya mulai melihat gunung dari “Zen and the Art of Motorcycle Maintenance”
    Pendekatan ini mengubah halaman panduan Confluence menjadi walkthrough yang setengah interaktif. Ini sisi yang sadar
    Sisi lainnya adalah automasi pengujian. Pada awalnya dimulai dengan tumpukan XPath yang overfit dan langkah-langkah yang tidak terdokumentasi. Setiap kali aplikasi berubah, langkah-langkah itu ditemukan kembali. Ini sisi yang tidak sadar
    Semoga kita bisa mencapai puncak dan menjalankannya dengan cepat, sambil tetap tahu bagaimana kita sampai ke sana dan mengapa menjadi seperti itu
  • Saya ingin hal-hal yang sudah bisa dilakukan dengan perintah dikerjakan langsung oleh skrip
    Cukup minta konfirmasi kepada pengguna seperti Execute command (y/N)?
    Saya benar-benar tidak suka menyalin dan menempel dari satu terminal ke terminal lain. Itu juga sangat menguras konsentrasi
    Cukup tanyakan kepada pengguna hanya untuk pekerjaan manual yang belum berupa perintah: Look up the e-mail address for foo. Paste it here: atau Put that shit in 1Password: Are you done (y/N)?

• Pendekatan yang menarik
  Namun pekerjaan yang dijadikan contoh hanya menunjukkan betapa tidak amannya cara perusahaan itu menerbitkan kunci SSH. Dalam praktiknya, pengguna seharusnya membuat private key sendiri, lalu hanya menyerahkan public key kepada administrator sistem untuk diberi hak akses. Pada titik mana pun administrator sistem tidak boleh memiliki salinan private key, bahkan sementara sekalipun. Jadi langkah 1Password itu sendiri seharusnya tidak diperlukan
  Sebagai catatan, saya adalah pembuat github-keygen, alat yang mengautomasi pembuatan kunci SSH khusus untuk akses GitHub serta pengaturan SSH dalam konteks tersebut
  https://github.com/dolmen/github-keygen

  • Membiarkan pengguna yang tidak terlatih mengelola kunci mereka sendiri juga tidak terlihat terlalu aman. Jadi intinya adalah memindahkannya ke skrip
  • Langkah pengguna harus membuat private key sendiri dan hanya menyerahkan public key kepada administrator sistem selalu menyebalkan untuk diimplementasikan
    Kami beralih dari SSH ke autentikasi berbasis sertifikat, dan tidak lagi memindahkan public key ke sana-sini. Seluruh prosesnya menjadi benar-benar lebih sederhana
  • Apakah ini benar-benar baseline-nya? Bukankah IT pada akhirnya memiliki semua bagian dari mesin kerja yang berisi private key? Saya paham kata sandi berbeda, tetapi private key tetap tersimpan di mesin

• Saya baru akhirnya mencoba pendekatan ini sekitar setahun setelah tulisan ini pertama kali terbit
  Karena bug di toolchain kami, runbook untuk hotfix kira-kira dua kali lebih rumit daripada proses rilis biasa
  Meski tidak mendapat apresiasi sebesar itu, sesuatu yang dulu hanya dipakai kira-kira sekali tiap 10 minggu untuk isu sev 1 atau pekerjaan epic tahap akhir menjadi dipakai rata-rata sekali seminggu, dan pada minggu tertentu sampai 3 kali. Karena tidak semuanya harus dijadikan feature toggle, kami bisa menggali utang teknis jauh lebih dalam
  Kalau perusahaan Anda kecil sehingga mudah mereplikasi data produksi ke lingkungan pra-produksi, hasil seperti ini mungkin tidak terlihat. Namun endpoint yang kami ajak berkomunikasi ada lebih dari 150, dan rata-rata sekitar 3 per layanan. Dataset-nya sangat banyak, dan sebagian dikumpulkan dengan cara yang mirip Kafka sebelum Kafka ada
  Hanya ada satu orang yang mencoba mereplikasi data produksi, dan orang itu pun kekurangan waktu serta energi sehingga hanya bisa melakukannya sekali atau dua kali setahun. Laju itu jauh lebih lambat daripada laju perubahan pelanggan dan fitur. Pada akhirnya kami harus mengutak-atik proses deployment blue-green dan jmeter untuk mencari tahu apakah kami sudah mendekati, serta bagaimana mengukur keberhasilan/kegagalan sebelum live
  Pada akhirnya yang menghambat orang-orang adalah proses build kecil-kecil yang rentan salah, dan baru terurai setelah saya mengotomatiskan setengahnya
  Belakangan, seiring penggunaan meningkat, saya mencari semua URL pada langkah manual dan memasukkannya ke lookup table di dalam tool, lalu juga menampilkannya dalam proses verifikasi umum untuk persetujuan rilis. Berkat itu, koordinator bisa bekerja sedikit lebih cepat dan dengan stres lebih rendah. Karena proses itu sangat menjengkelkan, tiga tim bergiliran menanganinya untuk berbagi beban

• Apakah ungkapan “menurunkan energi aktivasi otomatisasi tugas” pada akhirnya berarti skrip yang tidak melakukan apa-apa nanti akan memiliki langkah yang benar-benar mengotomatiskan sesuatu?
  Jika dilihat sebagai placeholder untuk otomatisasi masa depan, ini terasa seperti keseimbangan yang tepat antara otomatisasi dan efisiensi. Anda bisa melakukan percobaan pertama tanpa investasi berlebihan, dan menyisakan buah yang mudah dipetik nanti ketika upayanya menjadi lebih jelas bernilai

  • Benar
    Karena setiap langkah prosedur sekarang dienkapsulasi sebagai fungsi, teks dari langkah tertentu bisa diganti dengan kode yang benar-benar menjalankan tindakan secara otomatis

• class Foo(object): def run(self, context): ...
  Objek yang hanya punya satu method eksekusi sudah bawaan di Python. Itu adalah fungsi
  def foo(context): ...

  • Tapi bagaimana kita bisa bertahan hidup kalau tidak menelan abstraksi yang benar-benar rusak sekali sehari?
  • Keunggulan pendekatan awal adalah, saat nanti diperlukan, Anda bisa langsung menambahkan method private yang hanya dimiliki kelas tersebut
    Dalam pendekatan fungsi, jika butuh fungsi baru, Anda akan menambahkannya di level global. Kalau cuma satu-dua, itu sepenuhnya baik-baik saja, tetapi kalau makin banyak, akan ada banyak fungsi berjajar di level yang sama dan dependensi di antaranya tidak lagi jelas
  • Saya teringat Brain Will: https://www.youtube.com/watch?v=QM1iUe6IofM. Ia punya seri yang pada dasarnya mengeluh soal topik seperti ini
    Salah satunya membahas contoh-contoh menyederhanakan kode yang diabstraksikan secara tidak perlu

• Bagus, tetapi tidak bisa dihentikan
  Akan bagus kalau semua langkah ditampilkan lebih dulu, lalu tiap item dicentang seiring progres. Kadang lebih baik benar-benar bersiap dengan sudut pandang yang lebih luas
  Ringkasannya juga bisa ditinggalkan sebagai log di file
  Ada begitu banyak hal yang bisa diperbaiki sehingga, justru solusi paling sederhana mungkin yang terbaik

  • Dengan library command-line yang lebih baik, Anda bisa menampilkan checklist dan output eksekusi tiap langkah. Ini pendekatan yang cukup baik, terlepas dari langkah mana yang sudah diotomatiskan
    Namun skrip shell yang tidak melakukan apa-apa terlalu mudah untuk mulai dibuat sehingga sulit untuk tidak menyelesaikannya. Upaya itu mungkin lebih baik dipakai untuk mengotomatiskan satu langkah. Anda bisa terjebak di rawa yang menarik tetapi tidak terlalu produktif, seperti memilih library TUI mana yang dipakai atau bagaimana menyusun strukturnya
  • Senang ada yang menyebut bahwa ini “tidak bisa dihentikan”. Karena itu saya memakai Makefile alih-alih skrip Bash
    Tiap langkah adalah rule bernama *.done, dan setelah selesai akan membuat file .done. Anda bisa menghentikannya kapan saja, mengubah skrip untuk memperbaiki sesuatu, lalu melanjutkan dengan make
    Namun menulis Makefile itu benar-benar menyakitkan. Apakah ada solusi yang lebih baik?
  • Saat membuat hal seperti ini, saya meninggalkan state persisten agar bisa dihentikan. Misalnya untuk pekerjaan tahunan, jalankan seperti ./do-the-thing.sh 2025, lalu buat direktori 2025 untuk menyimpan state sudah sampai mana
    Saat langkah pertama disetujui, Anda bisa melakukan touch pada file 2025/first-step. Jika skrip mati atau dihentikan lalu dijalankan lagi, skrip memeriksa file itu dan melewati langkah pertama
    Ketika ada sesuatu yang berubah sehingga otomatisasi tidak berjalan, bagus kalau Anda bisa keluar tanpa kehilangan state, memperbaiki skrip, lalu menjalankannya lagi
    Biasanya saya membuat skrip hanya memberi tahu satu langkah manual berikutnya lalu keluar. Dengan begitu terminal bisa dipakai untuk hal lain. Skrip bisa dijalankan ulang dengan mudah lewat riwayat perintah
  • Apakah ini benar-benar kritik terhadap tulisannya? Dan Anda meninggalkan kesimpulannya begitu saja. Solusi mana yang “solusi paling sederhana”?
  • Saya pernah memakai skrip serupa, dan kalau tidak sengaja memasukkan alamat email yang salah, jadinya “sekarang bagaimana?”. Haruskah memulai ulang seluruh skrip? Terjebak di dalam skrip bisa jadi menyakitkan

• Ada juga diskusi-diskusi sebelumnya. Komentarnya banyak
  https://news.ycombinator.com/item?id=29083367 - 3 tahun lalu, 230 komentar
  https://news.ycombinator.com/item?id=20495739 - 6 tahun lalu, 124 komentar

• Saya tidak bisa melebih-lebihkan betapa saya menyukai pendekatan ini
  Saya berhasil menerapkannya di beberapa proyek. Contoh favorit saya adalah robot bedah senilai 30 juta dolar yang gagal dalam pengujian lab karena “faktor manusia”

  • Akan menyenangkan kalau Anda bisa membagikan satu contoh atau lebih secara lebih rinci, atau merangkum pengalaman dan tips. Saya ingin membacanya, baik di sini maupun dalam tulisan blog
    Saya berada di bidang lain, yaitu praktik hukum, tetapi ingin memikirkan bagaimana pendekatan ini bisa diterapkan di perusahaan kami

• Saya suka pendekatan ini. Bahkan pada sistem berbasis bahasa pemrograman dengan tingkat kompleksitas tertentu, saya sudah suka melakukan hal serupa. Di ranah pemrograman fungsional, tampaknya ini disebut holes
  Error not implemented pada interface juga mengikuti logika yang mirip, tetapi menurut saya ada nilai yang cukup besar dalam menulis hal-hal sepele yang menghasilkan output valid meski tidak bermakna untuk masing-masing dari beberapa bagian yang saling bergantung. Dengan begitu, proses membuat bagian-bagian itu menjadi lebih cepat, dan kemungkinan untuk menguji serta membuatnya satu per satu jauh lebih besar. Kebutuhan untuk menulis banyak bagian sekaligus sebelum mulai menguji jadi berkurang
  Seperti kasus penggunaan yang dibahas dalam tulisan, dalam konteks skrip kadang validitas pada level tipe seperti ini sulit menjadi penting. Sebab efek dari command line, dari sudut pandang fungsional, sebagian besarnya adalah efek samping. Namun karena prosesnya berjalan secara berurutan, dampaknya jauh lebih kecil, dan berkat prompt yang menunggu, kita bisa mempertahankan urutan kerja dengan biaya kecil sambil tetap menyimpan langkah manual yang bagaimanapun harus dilakukan meski tanpa skrip
  Scaffolding memang tidak sempurna, tetapi pada dasarnya berguna

• Secara teori bagus, tetapi dalam praktik sepertinya sulit
  Jika tim operasi melakukan pekerjaan yang sama berulang kali, lalu melihat bahwa skrip yang tidak melakukan apa-apa memang benar-benar tidak melakukan apa-apa, begitu mereka merasa sudah hafal langkahnya, atau merasa melakukannya secara manual lebih cepat atau lebih menarik, skrip itu akan segera tidak dipakai
  Saya sudah banyak menulis otomasi dan dokumentasi untuk tim operasi, tetapi membuat orang menggunakannya dan terus menggunakannya selalu menjadi masalah. Perubahan dokumentasi pun perlu diumumkan. Begitu orang merasa sudah bisa melakukan sesuatu, mereka cepat berhenti membaca dokumentasi
  Di dunia yang sempurna, pendekatan ini sangat masuk akal, dan untuk pekerjaan pribadi saya sendiri mungkin akan memakainya. Namun kenyataannya hampir tidak pernah sempurna. Kalau saya, saya mungkin hanya akan memakai cara ini ketika 90% sudah terotomasi dan tinggal 1 langkah yang belum bisa diselesaikan. Bahkan saat itu pun, sebagian tim operasi bisa saja melewati langkah manual tersebut dan menganggap semuanya adalah sihir yang sudah terotomasi

  • Biasanya sebagian bisa diotomasi, atau sebagian langkah manual bisa diverifikasi. Kalau begitu, tiba-tiba ia menjadi skrip yang melakukan sesuatu