Pelajaran Dari Isu LexoRank Jira

by

 

Isu LexoRank Jira: apa yang sebenarnya berlaku?

Dalam tempoh beberapa minggu lepas, pengguna mula mengadu – “tak boleh ubah status, keluar ralat ‘Error occurred while storing issue’”. Ralat ini muncul di pelbagai projek dan jenis isu, bukan satu dua sahaja. Masalahnya pula datang dan pergi – lepas restart node Jira, semuanya ok… kemudian beberapa jam atau hari, ia datang balik.
Ini menjadikan insiden ini bukan sekadar bug kecil, tetapi satu isu kestabilan yang betul-betul mengganggu operasi.

Bayangkan anda ada lebuh raya dengan ribuan kereta, dan semua kereta kena ikut turutan tertentu. Dalam Jira, turutan itu managed by LexoRank. Bila LexoRank mula tersangkut, seolah-olah lampu isyarat rosak – kereta masih ada, tetapi trafik mula sangkut, terutamanya bila orang cuba ubah status tiket. Itulah ringkasnya insiden LexoRank Jira yang terjadi dekat client dan vendor Atlassia

Insiden LexoRank Jira: langkah demi langkah penyelesaian

1. Kenal pasti corak: selalu bermula dengan LexoRank

Daripada log PostgreSQL dan log aplikasi Jira, nampak beberapa petunjuk konsisten:

  • Ralat seperti ERROR: canceling statement due to user request ketika mengemas kini jadual AO_60DB71_LEXORANK.
  • Mesej seperti “Unable to retrieve rank…” dan “Could not retrieve LexoRank value…” sebelum ralat workflow.
  • Operasi LexoRank kadang-kadang ambil masa lebih lama daripada timeout dalaman (1.5 saat untuk lock, sehingga 4 saat keseluruhan), lalu gagal.

Secara mudah, sistem cuba “susun semula barisan isu”, tetapi proses itu terlalu perlahan atau tersangkut kerana beban dan lock di pangkalan data.

2. Cuba baiki asas: konfigurasi DB dan vacuum penuh

Atlassian cadangkan dua tindakan asas pada PostgreSQL:

  1. Tukar validation-query dalam dbconfig.xml daripada select 1 kepada select version(); pada semua node Jira.
  2. Jalankan VACUUM(FULL, ANALYZE); pada pangkalan data Jira, dengan downtime terancang.

Hasilnya agak ketara: saiz pangkalan data produksi turun daripada kira-kira 52GB kepada 31GB.
Ibarat kemas stor yang penuh barang tak berguna – banyak ruang lapang balik, dan akses jadual jadi lebih cekap.
Namun begitu, insiden LexoRank Jira masih berulang beberapa hari kemudian.

3. Selidik beban dan sambungan: connection pool & RDS

Seterusnya, pasukan lihat dari sudut lain pula – konfigurasi connection pool dan RDS:

  • CPU RDS tidak tinggi (sering di bawah 50%), tetapi bilangan sambungan dan query kadang-kadang memuncak.
  • Ada banyak sambungan dalam keadaan idle, dan beberapa query berkaitan workflow serta LexoRank memblok yang lain.

Kami ubah beberapa nilai dalam dbconfig.xml, contohnya:

  • naikkan pool-max-size,
  • pendekkan pool-max-wait,
  • ubah kekerapan eviction sambungan idle.

Hasilnya, sistem jadi sedikit lebih stabil, tetapi masih belum “tenang sepenuhnya”.
Bug tetap muncul semula selepas beberapa waktu.

4. Fokus pada insiden LexoRank Jira dan plugin

Melalui beberapa pusingan log, thread dump, dan Java Flight Recorder (JFR), Atlassian mula nampak beberapa corak tambahan:

  • Ada penglibatan berat daripada ScriptRunner dan beberapa custom plugin (kelas com.XXXX.ipbu.*) semasa operasi LexoRank.
  • Ada beban daripada plugin lain seperti eazyBI, Table Grid Editor, Slack, dan Structure yang berjalan serentak.
  • Satu plugin khas, iaitu Versions, sering mencetuskan ralat:
    “Method InitCustomField: Cannot invoke ‘java.util.Collection.iterator()’ because ‘currentIssuevers’ is null.”

Ibarat ada beberapa add-on yang menambah kerja ketika kereta cuba bergerak di lebuh raya – ada yang log data, ada yang kemas kini hubungan isu lain, ada yang kira laporan.
Semuanya sah dari segi fungsi, tapi bila berlaku serentak, masa yang diambil menjadi lama dan LexoRank mudah kena timeout.

5. Eksperimen praktikal: reboot node, kecilkan kluster, dan cron restart

Supaya pengguna boleh terus bekerja, pasukan gunakan beberapa langkah sementara:

  • Restart node tertentu (contohnya node 1) bila ralat workflow muncul.
    Hampir setiap kali, selepas node itu di-restart, pengguna boleh ubah status semula.
  • Kecilkan bilangan node aktif (contohnya hanya 1–2 node untuk trafik pengguna), supaya proses reindex dan rebalance LexoRank berjalan lebih laju.
  • Pasang cron job pada node tertentu untuk restart Jira secara berkala (mula-mula setiap 6 jam, kemudian setiap 4 jam, kemudian 2 jam) sebagai cara “buang beban terkumpul”.

Langkah ini tidak menyelesaikan punca, tetapi seolah-olah “reset router WiFi” bila internet perlahan – bukan cantik, tapi cukup untuk kurangkan masa gangguan.

6. Dua langkah besar yang akhirnya menstabilkan sistem

Walaupun Atlassian menyatakan bug asal JSWSERVER-20691 tidak akan dibaiki secara kod teras, mereka tetap bantu semak dan mengesahkan dua perkara penting yang akhirnya beri kesan besar kepada insiden LexoRank Jira ini:

6.1 Naik taraf dan optimasi PostgreSQL RDS

Pihak infra menaik taraf RDS daripada db.m5.xlarge ke db.m5.2xlarge, dan menjalankan kerja penyelenggaraan:

  • VACUUM dan ANALYZE yang lebih teratur,
  • semakan semula parameter PostgreSQL,
  • pantauan rapat hit/miss cache untuk jadual LexoRank.

Graf penggunaan memori dan cache menunjukkan trend sihat – kebanyakan bacaan kini datang dari cache, bukan dari disk, jadi respon DB lebih konsisten.

6.2 Kemas kini dan kemas rumah pada plugin

Beberapa tindakan spesifik pada plugin turut diambil:

  • EToolCField – disahkan sudah tidak digunakan dan dimatikan di semua instance (prod, preprod, dev, test).
  • Versions – dibina semula ke versi 2.1 bagi menangani ralat currentIssuevers is null.
    Selepas kemas kini ini, ralat tersebut hilang dari log.
  • eazyBI – dikonfigurasi hanya berjalan pada satu node dedikasi supaya bebannya tidak mengganggu node lain.

Selepas gabungan langkah ini – upgrade DB, penyelenggaraan tetap, dan kemas kini plugin – insiden tidak lagi berulang untuk tempoh yang panjang.
Akhirnya, tiket diset sebagai selesai, dan node 1 dimasukkan semula ke dalam load balancer tanpa auto-restart cron.

Contoh mudah untuk faham keseluruhan insiden LexoRank Jira

Kalau kita ringkaskan insiden LexoRank Jira ini dalam satu analogi:

  • Jalan raya = pangkalan data PostgreSQL.
  • Kereta = isu-isu Jira yang perlu diurutkan.
  • Polis trafik = LexoRank yang urus turutan.
  • Waze, kamera, dan sistem tol = plugin seperti ScriptRunner, Versions, eazyBI, dan lain-lain.

Pada awalnya, jalan raya mula sesak kerana terlalu banyak sistem sampingan bekerja serentak.
Polis trafik (LexoRank) cuba susun semua kenderaan dalam masa tertentu, tetapi ada kereta yang lambat respon, ada persimpangan yang sempit (lock DB), dan ada alat tambahan yang tidak dioptimumkan (plugin dengan ralat).

Selepas:

  • lebuh raya dilebarkan (RDS dinaik taraf),
  • garis jalan dicat semula dan sampah dibersihkan (VACUUM/ANALYZE),
  • alat tambahan ditala semula atau dibuang (kemas kini dan buang plugin tertentu),

Barulah trafik jadi stabil semula, walaupun polis trafik asal (LexoRank) sebenarnya masih ada kekangan dalaman yang Atlassian tidak ubah.

Ringkasan: apa yang kita boleh belajar dari insiden LexoRank Jira

Daripada keseluruhan perjalanan panjang insiden LexoRank Jira ini, ada beberapa pengajaran yang jelas:

  • Masalah seperti ini jarang berpunca dari satu faktor sahaja; DB, konfigurasi connection pool, dan plugin semua saling berkait.
  • Workaround seperti restart node memang membantu, tetapi perlu diiringi siasatan mendalam dan penambahbaikan kekal.
  • Pantau log dan metrik (cache hit, lock, masa respon LexoRank) secara konsisten supaya corak halus boleh dikesan lebih awal.
  • Komunikasi rapat antara team, client, vendor operasi, dan vendor (Atlassian) sangat penting bila berdepan isu yang datang dan pergi.

Akhir sekali, insiden ini menunjukkan bahawa menstabilkan sistem bukan hanya tentang “padam api”, tetapi juga tentang memahami bagaimana semua komponen – dari pangkalan data hingga ke plugin kecil – saling mempengaruhi, dan kemudian menyusun semula semuanya supaya Lebuh Raya Jira boleh mengalir lancar semula.

Leave a Comment