04
lutego
2010
Od dzisiaj w moim miejscu pracy (helpdesk) pojawily sie nowe wytyczne.
Kiedy klient zglasza problem w systemie zgloszen (A) nalezy zarejestrowac zadanie w drugim systemie zgloszen (B), na ktorym nalezy rejestrowac swoj czas pracy nad wlasciwym zgloszeniem od klienta (uzywane przy rozbijaniu kosztow pracy kazdego pracownika na poszczegolne projekty). Zeby nie bylo nudno, gdy wymagana jest interwencja programisty nalezy mu napisac kolejne zadanie w systemie B.
W przypadku platnej uslugi nalezy w systemie A przy zgloszeniu zarejestrowac wycene, poczekac na akceptacje klienta, po czym w trzecim systemie ksiegowym (C) odnotowac platna usluge. Kiedy juz to wszystko zrobimy mozemy to wszystko pozamykac i popotwierdzac.
Dodatkowe uwagi -
W ten sposob problem ktory mozna klientowi rozwiazac w ~5 minut wymaga co najmniej 30 minut klikania w rozmaitych systemach. W przypadku platnej uslugi czas rozciaga sie o dodatkowe 30 minut, ze wzgledu na "wydajnosc" systemu ksiegowego. Nie uwzglednilem oczywiscie czasu realizacji prac programistow i negocjacji z klientem.
Mysle ze czas najwyzszy szukac nowej pracy, bo nie wiem jak bedzie wygladac kolejna iteracja tego mechanizmu.
Wesoło.
A nie może być ten B cały czas uruchomiony? Bo pewnie będzie musiał być.
A co do C, to nie wiem. Niestety pewnie potrwa, aż jakiś "kierownik" dojdzie do wniosku, że trzeba.
Jednak takie rozbuchanie to typowa korporacja...
generalnie B jest webowy, wiec po prostu typowe operacje pochlaniaja tyle czasu
a C to oczko w glowie nowego zarzadu. inna sprawa ze to powolne badziewie.
współczucie, nie ma jak wdrażać "ergonomiczne" rozwiązania ;)
14 września 2011, 22:19:53 | klucz ssh na gitorious |
Od niedawna przyłapałem się na tym że na gitorious.org przestał działać mój klucz ssh. Próba ponownej instalacji klucza powodowała jego odrzucanie ( " ssh key invalid " ).
Problem polega na tym ze zamiast user@host na końcu klucza trzeba wpisać swój email jaki podaliśmy przy rejestracji w gitorious.org. Być może problem nie dotyczy wszystkich, ale u mnie było to jedyne działające rozwiązanie.
04 lipca 2011, 12:48:34 | Tunelowanie esx po ssh |
Szybka notatka na przyszłość; aby wbić się na serwer ESX za pomocą vSphere poprzez tunel SSH, trzeba przeforwardować porty 443, 902, 903 oraz dodać wpis do hosts postaci
127.0.0.1 esxhost
bez tego nie pójdzie. Posiadanie wpisu określającego 127.0.0.1 jako "localhost" też z jakiegoś powodu nie wystarcza i dostaje się tajemnicze informacje o nieprawidłowym hoście, braku łączności itp.
02 sierpnia 2010, 20:12:02 | [mini] nietypowy problem CUPS |
ERRDOS - ERRbadaccess (Invalid open mode.) opening remote spool Test Page
W takiej sytuacji należy w windows w wlaściwościach drukarki odznaczyć "drukuj bezpośrednio na drukarkę". Dziwne, ale zostawię to sobie tutaj na przyszłość.