Tantangan Mengembangkan Aplikasi Ujian Online Berbasis Cloud

Share ke Sosmed

The Prolog

Corona membuat banyak sektor kelimpungan. Terlebih lagi sektor pendidikan. Heboh, bingung gimana ngajarnya. Belum lagi skill para guru, mumpuni ga ngajar jarak jauh alias remote? bisa ga menyeimbangkan dengan murid yang notebene sudah lebih paham tech ?

Dalam banyak perubahan ini, internal kami juga mengalami perubahan, terlebih dari sisi client. Banyak client sekolah mendaftar dan mulai lakukan penilaian atau ujian secara online. Berhasil kah? dari sisi bisnis, tujuan utama kita satu : online. Yes berhasil online, untuk data dan script itu tetap tanggung jawab client alias sekolah.

Sisi sekolah berhasil kah? oh belum tentu.
Tiket incoming.
“Pak kok database kita kosong?” He???
Looking into it. Ternyata hacked, hilang file dan database.
“Kami baru ujian tadi siang, kira-kira bisa tidak dibalikan datanya”
Nope, kami di jetorbit.com running backup database perhari pada waktu malam. Sedangkan ujian mereka dipagi hari dan hacked pada siangnya.

Dan ini tidak hanya satu sekolah, cukup banyak sekolah yang mengalami “hacked” ini. Kami telusuri masuk dari scriptnya, yang masuk dari form submit, mudah deh dilakukan inject shell.
Pertolongan pertama pada hal ini kami deploy simple but notorious, popup htpasswd auth! Yup berhasil untuk sementara menangani hacked.
Walaupun mengurangi kenyamanan.

The Beginning

Pada saat itu, isu-nya covid akan masih lama terjadi, kami mulai mengambil langkah. Diskusi team.

Kami putuskan untuk mengembangkan produk, yang bisa untuk ujian online, yang mudah, yang saat itu baru sedikit, hanya dalam hitungan sebelah tangan saja. kurang dari 5 biji. Mana dari itu salah satunya google form pula. ribet dan juga bukan fungsi utamanya untuk ujian online.

Kita namakan Ujione
Karena setiap siswa yang ujian ingin menjadi nomer satu. 😎

Fokus kita waktu itu adalah : jadi dulu!
Urusan hit oleh banyak siswa, mudah! (kala itu). Monolith dan pakai semi manual scaling, load balancer. Kita sudah pernah lakukan ini di projek salah satu provider telekomunikasi warna biru juga.

Beberapa bulan develop apps. Jadi, siap running dengan tetap mendengarkan masukan user/guru/siswa sekolah. Hingga ratusan yang mendaftar hanya dalam kurun sekitar 3 bulan. Mungkin juga karena kita sediakan trial 60 hari, dengan timbal balik harus ada masukan ke aplikasi.
Jadi lah!

The Issue

Makin banyak pemakai, mulai ada keluhan akses. Apps kami mulai kewalahan dengan jumlah concurrency. Scaling semi manual ternyata banyak membutuhkan waktu terbuang, overhead.

Tim Assemble!

Pada tim saat itu kami rembug lagi. Hasil akhir, kita perlu refactoring. Not all, but our infrastructure and the frontend.

The Resolve

Untuk dapat menghandle luebih banyak user, tanpa limitasi.
Kami memberlakukan microservice ready pada sisi backend dan frontend. Setiap service kami pisah. Setup CI/CD for the sake of development and scalling. Setup kubernetes and its tools. Untuk memudahkan scale.

Dalam persiapan ini, riset awal sangat penting. Tools apa yang ingin digunakan, kenapa? karena ketika sudah menggunakan tools itu, tools/apps yang digunakan akan terus dipakai dan menjadi bagian yang terus digunakan baik error dan pengembangannya perlu dipertimbangkan.

Tips mudah untuk memilih tools/vendor/script/apps yang kita gunakan untuk production adalah : cek latest update nya. Apakah tahun ini? apakah bulan ini? apakah 2 tahun lalu? 😎

Dalam pemilihan tools ini, tetap ikutkan tim untuk berdiskusi. Karena ini kerja tim, dan bukan kerja sendiri. Jadi infokan, dari sisi masing masing tim melakukan review pada tools yang sesuai task mereka.

  • Kapan update terakhir tools itu?
  • Apakah ada support jika something goes wrong? jika opensource, apakah komunitas nya aktif? jika aktif, dimana cara berkomunikasi? email kah? discord kah? atau forum?
  • Bagaimana integrasi tools itu dengan tools pendukung lainnya? banyak tidak? mudah tidak?
  • Apakah ada dokumentasi? Lengkap tidak?
  • Jika itu berbayar, berapa price? apa beda dengan yang free? Apakah betul-betul perlu pada tahap awal menggunakan yang berbayar?
  • Berapa lama perkiraan untuk riset dan mempelajari tools itu? Seberapa familiar dengan tools itu?

Kira kira itu pertanyaan yang bisa dilontarkan pada tim atau masing-masing individu tim sebelum memutuskan untuk menggunakan tools yang dipilih.

Diatas baru tools. Kita lanjut ke model riset. Ini yang bisa kami lakukan sebelumnya

  • Fokus pada solving problem. Problem utama sebelumnya adalah karena konektivitas.
  • Cari cara untuk bisa handling banyak concurrency dalam satu waktu.
  • Cari framework/tools/core code untuk handling itu.
  • Apakah programmer yang tersedia bisa menggunakan? Jika tidak, bagaimana cara solvingnya?
  • Dimana bottlenecknya? cari. Apakah di frontend? apakah backend? apkaah di koneksi antar api? apakah di server? atau optimasi server dan jaringan? cari.
  • Tes Tes dan Tes. Tes semua possibility yang bakal terjadi di apps itu.
  • Lakukan backup berkala juga. Ini penting before all f*ked up

Setelah step-step diatas, buat dua sisi deployment, satu stagging satu production. Simulasi pada stagging paling tidak harus sama dengan production. Bisa dengan less power hardware, namun tetap dengan struktur dan flow yang sama.

Misal production menggunakan CI/CD, maka stagging juga sama. Kami gunakan Gitlab, di gitlab bisa dipisah saat ada kode push untuk stag dan prod. Mau pisah repo juga monggo.

The Rest

Tahap selanjutnya, continues improvement. Ini bagai maraton panjang. Finishnya ada pada goalnya. Kalau terlalu panjang memang terlihat melelahkan. Bagi goal menjadi goal-goal kecil. Pencapaian-pencapaian kecil yang tim bisa well deserverd untuk di selebrasikan.

Mendengar dan mempertimbangkan input dari user atau pengguna, dapat dijadikan poin pada “user tester”. Ini membantu tim dev untuk mudah mendapatkan tes secara realtime 😀

Beberapa sekolah atau instansi masih menggunakan sistem lama. Moodle. Namun saat dilakukannya ujian online berbarengan, bisa kolaps sistem infra yang mereka pakai karena tidak mendukung digruduk sak sekolah.

Ada banyak banget apps yang mungkin orang bilang serupa, seperti ruangguru, zenius dan sebagainya. Namun apps tersebut sampai saat ini sepengetahuan saya tidak menyediakan platform untuk ujian secara bersamaan dalam satu waktu. Apps itu kami anggap sebagai konten provider elearning. Well, di Ujione sendiri kami juga kembangkan fitur elearning sebagai fitur tambahan.

Selain sisi teknis diatas, sisi market pun perlu dilihat perkembangannya. justru sebelum memulai pengembangan produk, hal pertama yang perlu digarap adalah riset pasar. Lakukan secara teliti, dan ambil action segera. Jangan lama.

Dan inilah akhir dari sebuah memo tentang catatan tantangana pengembangan apps ujian online di indonesia.

Sekian dan God Speed.

Alhamdulillah

Share ke Sosmed

Leave a Reply

Your email address will not be published. Required fields are marked *