Açık Kaynak Ticket Sistemi: Şirket İçi IT Destek Çözümü

Açık Kaynak Ticket Sistemi: Şirket İçi IT Destek Taleplerini Yönetmek İçin Bir Sistem Yazdım

Şirket içi IT destek süreçlerini yönetmek için kullanabileceğiniz, açık kaynak bir ticket sistemi geliştirdim ve MIT lisansıyla yayınladım. Sistem tamamen kendi sunucunuzda çalışıyor, Docker ile kuruluyor ve talep eden kullanıcılardan hesap açmasını istemiyor.

Kodun tamamı GitHub’da: https://github.com/mahmutyum/ticket-system · Tanıtım sitesi: iticket-system.netlify.app

Neden yeni bir yardım masası yazılımı?

IT tarafında çalışan herkesin bildiği bir sorun var: destek talepleri WhatsApp gruplarında, e-postalarda ve koridorda söylenen cümlelerde kayboluyor. Kimin neyi ne zaman istediği, ne kadar sürede çözüldüğü, hangi konunun tekrar tekrar geldiği ölçülemiyor.

Hazır çözümleri denedim ve iki grupta topladım:

• Kurumsal bulut servisleri (Zendesk, Jira Service Management, Freshdesk) — kullanıcı başına aylık ücret istiyor, verileriniz dışarıda duruyor ve iç ağa kapalı bir kurulum için tasarlanmamışlar.
• Klasik açık kaynak alternatifler (osTicket, GLPI gibi) — güçlüler ama kurulumları ağır, arayüzleri yorgun ve en önemlisi: talep açacak kişiden hesap oluşturmasını istiyorlar.

İkinci madde benim için kırılma noktasıydı. “Yazıcım çalışmıyor” demek isteyen bir muhasebe personeline önce kayıt formu, sonra e-posta doğrulama, sonra şifre belirleme ekranı göstermek, sistemin hiç kullanılmamasının en garantili yolu. İnsanlar o zahmete girmektense yine sizi arıyor — ve sistem ölü doğuyor.

Bu yüzden sıfırdan yazmaya karar verdim.

Talep eden için: giriş yok, şifre yok

Sistemin temel tasarım kararı bu. Destek talebi açan kişi hiçbir zaman giriş yapmıyor.

Akış şöyle işliyor:

1. Kullanıcı talep formunu açıyor: şirket, lokasyon ve kategori seçiyor.
2. Seçtiği şirkete özel tanımlanmış dinamik alanları dolduruyor (örneğin bir şirkette “demirbaş numarası”, diğerinde “şube kodu” sorulabilir).
3. İsterse ekran görüntüsü veya dosya ekliyor.
4. Talebi gönderdiğinde kendisine özel bir takip bağlantısı veriliyor.

O bağlantı kullanıcının tüm deneyimi: talebin hangi aşamada olduğunu canlı görüyor, IT ekibinin yazdığı yanıtları okuyor, kendisi cevap yazıyor ve yeni dosya ekleyebiliyor. Bağlantısını kaybederse ticket numarası ve e-posta adresiyle yeniden erişebiliyor.

Sonuç: şifre sıfırlama talebi açmak için şifre sıfırlaması gereken bir ticket sistemi paradoksu ortadan kalkıyor.

IT ekibi için: rol bazlı yönetim paneli

Talep eden tarafı ne kadar sade tutulduysa, IT ekibinin paneli o kadar detaylı:

• Kontrol paneli — açık/kapalı talep istatistikleri, SLA durumu, üzerinize atanmış işler.
• Talep yönetimi — liste, filtre, arama, durum ve atama değişikliği, toplu işlem.
• İç not / public yanıt ayrımı — ekip içi konuşmalarınız (“bu kullanıcı geçen ay da aynı şeyi yaptı”) talep edene asla görünmüyor.
• Yerinde destek takvimi — randevu oluşturma, süre belirleme, takvim görünümü.
• Görev yönetimi — ticket’a bağlı olmayan işler için, çoklu atama ve yorumlarla.
• Raporlar — talep dağılımı, personel performansı, kategori kırılımı, SLA trendi ve CSV export.

Roller admin, it_manager ve it_staff olarak ayrılmış; her rol yalnızca yetkisi olan ekranı görüyor.

Holding ve grup şirketleri için çok şirketli yapı

Sistemin ayırt edici tarafı burası. Tek kurulum üzerinden birden fazla şirketi birbirinden izole şekilde yönetebiliyorsunuz:

• Her şirketin kendi kategorileri, kendi özel alanları var.
• Her şirketin kendi logosu ve tema rengi — hangi alan adından girildiyse o şirketin markası görünüyor.
• Her şirket kendi SMTP sunucusundan e-posta gönderiyor; tanımlı değilse global ayara düşüyor.
• Personel yalnızca atandığı şirketlerin verisini görüyor. Bu kural veritabanı sorgusu seviyesinde uygulanıyor, arayüzde gizleme yöntemiyle değil.

Birden çok iştiraki olan gruplarda tek bir IT ekibi tüm şirketlere hizmet verirken veriler karışmıyor.

Arka planda çalışanlar

• E-posta ve SMS bildirimleri BullMQ kuyruğuyla asenkron gönderiliyor; başarısız olursa 3 kez, artan bekleme süreleriyle tekrar deneniyor.
• SLA kontrolü her 5 dakikada bir çalışıyor, kategori bazlı yanıt ve çözüm süreleri tanımlanabiliyor.
• Canlı güncelleme SSE (Server-Sent Events) ile — panel açıkken sayfa yenilemeden yeni talepler düşüyor.
• Çift dil (Türkçe/İngilizce) — arayüz tarayıcı diline göre açılıyor, tek tıkla değişiyor. Daha önemlisi: bildirim e-postaları alıcının diline göre gidiyor. Yabancı ortaklı şirketlerde İngilizce konuşan personel İngilizce, Türk personel Türkçe bildirim alıyor.

Güvenlik tarafında ne var?

DevSecOps tarafından gelen biri olarak bu kısmı ciddiye aldım:

• Şifre kasası — sunucu, cihaz ve servis şifrelerini AES-256-GCM ile şifreli saklıyor. Her görüntüleme audit kaydına düşüyor: kim, neyi, ne zaman açtı belli.
• İki faktörlü doğrulama (TOTP) — opsiyonel, yetkili hesaplar için uyarı gösteriliyor.
• Dosya yükleme sertleştirmesi — uzantı istemcinin gönderdiği isimden değil, doğrulanmış MIME tipinden türetiliyor; içerik magic-byte kontrolünden geçiyor; indirmeler yetki kontrollü.
• Fail-closed yetkilendirme — şüpheli durumda erişim kapanıyor, açılmıyor.
• CSV formül enjeksiyonu, SSRF ve şablon kaçış korumaları mevcut.

Dürüst olmam gereken bir nokta var: bu sistem iç ağ veya VPN arkasında çalışmak üzere tasarlandı. Talep portalı bilinçli olarak kimlik doğrulaması yapmıyor — erişim, tahmin edilemez bağlantı token’larına dayanıyor. Doğrudan internete açacaksanız önüne kendi erişim kontrol katmanınızı (VPN, IP kısıtlaması veya kimlik doğrulayan reverse proxy) koymanız gerekiyor. Bu detay projenin SECURITY.md dosyasında da açıkça yazıyor.

Docker ile kurulum

Sunucunuzda Docker dışında hiçbir şey kurulu olmasına gerek yok:

git clone https://github.com/mahmutyum/ticket-system.git
cd ticket-system
cp .env.example .env

Zorunlu secret’ları üretin (varsayılanları yok, boşsa sistem açılmaz)

openssl rand -base64 48 # JWT_SECRET
openssl rand -base64 48 # JWT_REFRESH_SECRET
openssl rand -hex 32 # CREDENTIALS_ENC_KEY

docker compose up -d –build

Veritabanı şeması otomatik uygulanıyor. Production kurulumunda yalnızca frontend portu dışarı açılıyor; backend, PostgreSQL ve Redis dahili Docker ağında kalıyor. Coolify ve Nginx Proxy Manager ile uyumlu çalışacak şekilde hazırlandı.

Detaylı kurulum ve sorun giderme adımları kurulum dokümantasyonunda (https://github.com/mahmutyum/ticket-system/blob/main/docs/kurulum.md) yer alıyor.

Kimler için uygun, kimler için değil?

Uygun: 20-500 kişilik şirketlerin iç IT ekipleri, birden fazla iştiraki olan gruplar, kendi sunucusunda veri tutmak isteyen kurumlar, kurumsal helpdesk lisans maliyetinden kaçınmak isteyenler.

Uygun değil: Dış müşteriye açık, internet üzerinden erişilen bir müşteri destek portalı arıyorsanız — sistem bu senaryo için tasarlanmadı. Ayrıca ITIL süreç yönetimi, varlık envanteri (CMDB) veya değişiklik yönetimi arıyorsanız GLPI gibi daha kapsamlı araçlara bakmanız daha doğru olur.

Sık sorulan sorular

Ticket sistemi ücretli mi?
Hayır. MIT lisansıyla açık kaynak olarak yayınlandı; ticari kullanım dahil ücretsiz, kullanıcı başına lisans ücreti yok.

Kaç kullanıcı destekliyor?
Kullanıcı sınırı yok. Sınırı sunucunuzun kapasitesi belirliyor.

Verilerim nerede tutuluyor?
Tamamen kendi sunucunuzda. Dışarıya hiçbir veri gönderilmiyor, üçüncü parti servis bağımlılığı yok.

Mevcut e-posta sunucumla çalışır mı?
Evet. Global bir SMTP tanımlayabilir, ayrıca her şirket için ayrı SMTP ayarı girebilirsiniz.

Türkçe destekliyor mu?
Evet, arayüz ve bildirimler Türkçe/İngilizce çift dilli. Bildirimler her alıcıya kendi dilinde gidiyor.

Kurulum ne kadar sürer?
Docker kurulu bir sunucuda temel kurulum birkaç dakika. Şirket, kategori ve SMTP yapılandırmasıyla birlikte yarım günlük bir iş.

Proje aktif geliştiriliyor, ilk kararlı sürümü (v1.0.0) yayınlandı. Katkılar, hata bildirimleri ve öneriler açık:

👉 https://github.com/mahmutyum/ticket-system — yıldız bırakmanız projenin görünürlüğüne katkı sağlıyor.

Kurulumda takıldığınız bir yer olursa yorumlara yazabilir veya GitHub üzerinden issue açabilirsiniz.