CapordiaBir talebin asgari sözleşmesini yazmak
Kullanılabilir bir talep; bir sahibi, bir projeyi, hazır bir girdiyi, tanımlanmış bir komut veya prosedürü ve beklenen bir sonucu adlandırır. Eşzamanlı kart sayısını, kart başına belleği, tahmini süreyi ve çıktıların hedefini belirtir. Son olarak teslim tarihini, bu tarihin nedenini ve bir gecikmeyi veya kapsam daralmasını kabul etmeye yetkili kişiyi belirtir.
Bu bilgilerin eksikliği yüksek bir öncelikle gizlenmemelidir. Girdileri hazır olmayan bir görev, proje önemli olsa bile kabul edilemez olarak kalır. Eksik olanı sorun ve yeniden değerlendirme noktasını belirleyin. Kuyruk böylece bir karar aracı haline gelir: herkesin kendiliğinden ele alınmasını umduğu, başlatılamayan talepler deposuna dönüşmez.
Kabul, rezervasyon ve geçiş hakkını birbirinden ayırmak
Kabul, görevin incelenebileceğini doğrular: yetkiler, veriler, uyumluluk, kapasite ve prosedür mevcuttur. Bir rezervasyon ise kararlaştırılmış bir zaman aralığını veya kaynağı korur. Öncelik, mevcut bir kaynak için yarışan kabul edilebilir talepler arasındaki sırayı seçer. Bu üç karar farklı kişilere ait olabilir; teknik ihtiyacın örtük bir şekilde onaylanmasını önlemek için bu dağılımı açık hale getirin.
Boş bir kart tüm görevleri kabul edilebilir kılmaz. Gerekli disk eksik olabilir, bir lisans eşzamanlılığı sınırlayabilir veya önceki sonuç gerekli olabilir. Tersine, teknik olarak hazır bir talep bir takvim kararını bekleyebilir. Kimsenin yorumlayamadığı basit bir sayısal sıra yerine anlaşılır bir neden ve bir sonraki eylemi gösterin.
Ayrıcalığa dönüşmeyen öncelikler tanımlamak
Birkaç okunabilir sınıf seçin; örneğin doğrulanmış dış teslim tarihi, rutin iş ve kesin tarihi olmayan keşif. Bir sınıfı kimin atayabileceğini ve bunu hangi belgenin gerekçelendirdiğini belirleyin. Bir sınıf içinde, bir kıdem veya rotasyon kuralı seçimi öngörülebilir kılabilir. Yüz küçük başvuruya bölünmüş bir talep, başka bir ekibin talebinden mekanik olarak yüz kat daha fazla şans elde etmemelidir.
Slurm özellikle kabul edilebilir bekleme süresi ile tahsis edilen ve tüketilen kaynaklara dayanan adil paylaşımı birbirinden ayırır. Bu, iki farklı soruyu örnekler: ne zamandan beri bekleniyor ve şimdiye kadar hangi pay kullanıldı? Kuralınız manuel kalabilir. Parametrelerini anlamadan bir puan formülünü benimsemeyin; belirli bir zamanlayıcının ağırlıkları evrensel bir hakkaniyet ölçütü oluşturmaz.
Kurgusal örnek: bir acil durumu diğerlerini kovmadan almak
Kurgusal ekip "Planlar ve İşaretler" tek bir kart kullanıyor. Saat 9'da Planlar projesinden bir görev, 11'e kadar onaylanmış bir zaman dilimine sahip; kesintiye uğratılamaz. İki tam talep bekliyor: İşaretler, kırk dakika ve Eskizler, seksen dakika. Saat 9.30'da İşaretler tarafından öğlen yapılacak bir inceleme için talep edilen otuz dakikalık bir acil durum geliyor. Bu sürelerin tümü eğitim amaçlı varsayımlardır, ölçüm değildir.
Yerel kural, onaylanmış bir acil durumun, hâlihazırda başlamış bir işi kesintiye uğratmadan bir sonraki serbest bırakma noktasına geçmesine izin verir. Bu nedenle acil durum saat 11'de başlar ve teorik olarak 11.30'da biter. Ekip daha sonra, acil durumuyla hâlihazırda hizmet almış olan İşaretler'in kuyruğu tekeline almaması için geçiş hakkını Eskizler'e verir. Bu istisna ve İşaretler'in beklenen yeni başlangıcı ilgili sorumlulara duyurulur.
| Varsayımsal zaman aralığı | Proje | Geçiş nedeni |
|---|---|---|
| 9–11 | Planlar | Zaten başlamış, kesintiye uğratılamaz zaman aralığı |
| 11–11.30 | İşaretler, acil durum | Öğleden önce doğrulanmış dış teslim tarihi |
| 11.30–12.50 | Eskizler | İşaretler'e hizmet verilen acil durum sonrası rotasyon |
| 12.50–13.30 | İşaretler, rutin talep | Sonraki kabul edilebilir talep |
Uzun işlerin açlığını önleme
Her zaman en kısa talebi sunmak, görünüşte akıcı bir kuyruk oluşturur ama uzun bir işi süresiz olarak erteleyebilir. Ayrılmış pencereler veya duyurulmuş bir bekleme yaşına göre yeniden inceleme öngörün. Bu eşik, tanımlanması gereken bir iç kuraldır; garanti edilen bir hizmet süresi değildir. Uzun iş gerçekten mevcut dönemi aşıyorsa, kabulü çıkmaz bir bekleyiş yerine yeni bir takvime yol açmalıdır.
Kısa boşluklar, ayrılmış bir başlangıcı ertelemeyen görevleri barındırabilir. Bu karar, inandırıcı bir tahmin, gerçekten uyumlu bir kaynak ve pencere içinde bitirme olasılığını gerektirir. Takvimin tüm boşluklarını yeni taahhütlerle doldurmayın. Bir sapmayı absorbe etmeye yönelik rezerv, bedava bir zaman dilimi değildir; kullanımının bir sorumlusu ve bilinen bir sonucu olmalıdır.
Kapsamı net bir iptal öngörme
Kimin kendi talebini, bir projenin talebini veya diğer işler için tehlikeli hale gelen bir yürütmeyi iptal edebileceğini belirleyin. Henüz beklemede olan bir talep için sıra düzeninden çıkarıldığını doğrulayın. Başlatılmış bir iş için önce neyin kesilebileceğini, neyin korunması gerektiğini ve çıktılarını kimin beklediğini kontrol edin. Bir "iptal talep edildi" mesajı, kaynağın serbest olduğunu henüz kanıtlamaz.
Teknik etkileri belirleyen asıl araçtır. scancel belgeleri bir işi ve adımlarını, ayrıca bir sinyal göndermeyi ve işin iptalini birbirinden ayırır. Eşdeğer bir araç kullanmadan önce ilgili tanımlayıcıyı ve kapsamı kontrol edin; kolaylık olsun diye genel bir seçimden kaçının. Ardından süreçlerin sona erdiğini ve kısmi çıktıların nereye gittiğini doğrulayın. Veri kurtarma planı, bu öncelik kuralından ayrı olarak taşıma dosyasında ele alınır.
Denemeleri sınırlama ve hatalı bir görevi izole etme
Yürütmeden önce, aynı neden için kaç otomatik denemenin kabul edilebilir olduğuna karar verin. Geçersiz bir girdi, yeniden başlatıldığı için doğru hale gelmez; geçici olarak erişilemeyen bir bağımlılık, doğrulamadan sonra yeni bir denemeyi haklı çıkarabilir. Kural; azami sayıyı, olası süreyi ve yeniden inceleme sorumlusunu belirtmelidir. Her yeni gönderimde sıfırlanan bir sayaç bu korumayı ortadan kaldırır: art arda gelen talepleri aynı soruna bağlayın.
Kararlaştırılan sınıra gelindiğinde, hatalı görevi normal rekabetten çıkarın ve okunabilir bir gerekçeyle mantıksal karantinaya alın. Kabul edilebilir işlerin geri kalanı devam edebilir. Yeniden dahil etme; bir düzeltme veya onaylanmış bir açıklama, küçük ve hedefli bir kontrol ve sahibinin kararını gerektirir; eski bir aciliyetin önceliğini otomatik olarak geri almaz. Bu prosedür, başarısızlık sonrası kabulü düzenler. Çıktıların saklanması ve kurtarılması taşıma dosyasında kalır; burada yeni bir durum kaydı uydurulmaz.
Politikayı dört basit durumla test etme
Kuralı proje sorumlularına dört vakayla gözden geçirtin: iki aynı talep, kesilemez bir iş sırasında bir aciliyet, kısa taleplerle çevrili uzun bir görev ve acil olarak sınıflandırılmış eksik bir talep. Her vaka için farklı bir kişi aynı sonraki başlangıca varmalı ya da gerekli hakemliği açıkça belirlemelidir. Yalnızca yazarının anladığı bir kural uygulanmaya hazır değildir.
Ayrıca bir iptalin aynı kapasiteyi iki kez vermediğini ve bloke olmuş bir işin başka bir kabul edilebilir işi gereksiz yere engellemediğini kontrol edin. Bu doğrulamalar kâğıt üzerinde başlayabilir; bir zamanlayıcının uygulandığını kanıtlamazlar. Daha sonra otomatikleştirirseniz, bir proje taahhüdünü buna bağlamadan önce aynı senaryoları yapılandırılmış araç üzerinde yeniden üretin.
Kuyruğun sunduğu hizmeti ölçme
Kabul edilebilir taleplerin sınıf ve proje bazında beklemesini ve blokaj nedenlerini izleyin. Beklemeyi, doluluğu ve kabul edilen sonuca kadar geçen süreyi birbirinden ayırın. Tek bir tamamlanan iş toplamı, sürekli ertelenen bir ekibi ya da biriken acil görevleri gizleyebilir. Tahmini ve gerçek doluluk arasındaki farklara da bakın: bunlar gelecekteki rezervasyonları doğrudan etkiler.
Politikayı ekiple birlikte seçilen bir tarihte ya da eksik bir kuralı ortaya çıkaran bir olayın ardından gözden geçirin. Kuralları birer birer değiştirin ve değişikliğin mevcut talepler üzerindeki etkisini duyurun. Beklenen sonuç, açıklanabilir bir geçiş sırası, izlenebilir istisnalar ve tutarlı bir takvimdir. Bu, ne Capordia hesap kimlik doğrulamasının ne de makine izinlerinin yerini alır ve hiçbir destek taahhüdü doğurmaz.
Karar vermek için sorular
Bir acil durum her zaman ilk sıraya mı geçmelidir?
Bir acil durum kabul edilebilir, gerekçelendirilmiş ve ortak kurala göre onaylanmış olmalıdır. Devam eden bir işi kesintiye uğratabilir hale getirmez. Geçiş noktasını, yerleri değiştirilen talepleri ve bunların teslim tarihleri üzerindeki etkiyi üstlenen kişiyi tanımlayın.
Bir ekibin zaman dilimlerini tekeline alması nasıl önlenir?
Hâlihazırda elde edilmiş kaynaklara ve diğer projelerin beklemesine bakın, ardından açık bir rotasyon veya paylaşım kuralı uygulayın. Ham talep sayısı bir adalet ölçüsü değildir. Uzun işlerin nasıl ele alınacağını da planlayın.
Bu yöntem Slurm kurulumunu gerektiriyor mu?
Hayır. Slurm belgeleri bazı ayrımlara ışık tutar, ancak politika öncelikle ekibin koordinasyon aracında uygulanabilir. Olası bir otomasyon kendi yapılandırmasını ve denetimlerini gerektirir; hiçbir zamanlayıcının sağlandığı varsayılmaz.