Generalne bugi idą zwykle do standardowego developmentu i oni je poprawiaja.
To chyba w polskich garażowych firmach jest tak, że programista jest jednocześnie developerem i suportowcem. Jest to bardzo nieefektywne, bo po pierwsze jest to odrywanie ludzi od roboty, po drugie dawanie im zadań w systemie, którego nie znają powoduje zazwyczaj tylko więcej błędów.
W normalnych firmach jest ścisły podział: developerzy tworzą nowe systemy, a support je później wspiera.
Dla wyjaśnienia:
L1 = helpdesk dla użytkowników (czyli pani Grażynka nie wie jak wydrukować raport)
L2 = helpdesk dla adminów (czyli admin Janusz nie wie jak poprawnie skonfigurować aplikacje na klastrze z VPNami pomiędzy nodami)
L3 = helpdesk w sytuacji kiedy nie da sie rozwiązać problemu w L2, tzn problem nie wynika z błędnej konfiguracji systemu, tylko z tego że system czegoś nie wspiera a powinien. Zwykle wiąże sie to ze zmianami w kodzie, nierzadko u konkretnego klienta.
A skąd taki podział?
L1 rozwiązuje problemy spowodowane przez użytkownika, czyli niepoprawne użycie systemu.
L2 rozwiązuje problemy z danymi - np. system zewnętrzny dostarczył plik w niepoprawnym formacie (np. data niemiecka zamiast angielskiej), więc plik trzeba poprawić i przepuścić przez system. Inny przykład - ponowne uruchomienie jakiegoś procesu, który wykrzaczył się ze względu na błąd sieci albo timeout bazy. L2 generalnie gmera w bazach danych i sprawdza, czy wszystko się zgadza.
L3 zajmuje się kodem. Jeśli mamy pewność, że użytkownik robi to, co powinien i dane dostarczane na wejściu są prawidłowe, a mimo to system zwraca niepoprawne wyniki albo nie działa, to znaczy, że jest jakiś bug, więc trzeba go znaleźć i naprawić.
Żadne z tych zadań nie jest związane z jakąkolwiek administracją systemami operacyjnymi, sieciami czy ich konfigurowaniem. Support systemów informatycznych to nie jest to samo co support infrastruktury IT.