Onderwerp: Brutele problemen

On 14 Nov 2003 10:03:38 GMT, frank@openminds.be wrote:

>Sven DE TROCH <sven@nt-admin.com> wrote:
>> On 13 Nov 2003 12:08:30 GMT, frank@openminds.be wrote:
>
>
>> Een (nieuwe) klant van ons klaagde deze avond ook over veel
>> packet-loss, een site uploaden via ftp lukte maar beetje bij beetje.
>> Zou dus idd op een probleem(pje) kunnen wijzen bij Brutele.
>> Voor de rest ken ik die provider niet echt.
>
>Sven, heeft je klant nog last? Hier is er niks verbeterd. Een mtr naar
>die doos:
>
>8% packetloss op laatste brutele router, 14% op de doos zelf!
>
> 6. fas-1-0-ias-be-bru-dr08.KPNbelgium.be 0% 1727 1727 12 11 17 243
> 7. ias-router-Brutele.KPNBelgium.be 0% 1727 1727 13 11 17 301
> 8. 213.213.254.50.brutele.be 1% 1726 1727 13 11 14 81
> 9. 212.68.196.97.brutele.be 8% 1600 1727 14 12 25 111
>10. mail.XXXXXX.XXX 14% 1497 1727 32 18 60 499
>
>
>Vriendelijke groeten,
>Frank Louwers

Frank,

geen idee, de site is er (uiteindelijk, met brokjes en beetjes) toch
opgeraakt :-)

--
Sven De Troch
http://www.sitehosting.be

houghi <houghi@houghi.org> schreef:

>> Ik denk dat als een bedrijf als XS4ALL een betere service geeft, dit in
>> grote mate te maken moet hebben met het feit dat dit een 'relatief
>> kleinere boîte' is.
>>
>> Akkoord of niet?
>
> Yep. De syteembeherders zitten zelf ook wel aan de telefoon. De afstand
> tussen de helpdesk en de systeembeheerders is dan heel veel kleiner.
> Normaal ook. Als daar iemand even wat vraagd, krijgen ze gewoon
> antwoord.
>
> Stel dat alle helpdeskers bij een grotere provider bijiemand van
> systeembeheer komt vragen om wat extra uitleg, dan mag je blij zijn als
> de computers nog aanstaan.

Dat is op te lossen door meer systeembeheerders aan te nemen, en de zon
ontstane reserve in te zetten "naast" de helpdesk...

--
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9

houghi wrote:

>Serge van Ginderachter wrote:
>
>
>>Serge van Ginderachter wrote:
>>
>><snip /XS4ALL>
>>
>>
>>
>>>Vanuit mijn beperkte ervaring met hen moet ik dus zeggen:
>>>
>>> Goe bezig ;-)
>>>
>>>
>>>
>>Graag jullie mening:
>>
>>Ik denk dat als een bedrijf als XS4ALL een betere service geeft, dit in
>>grote mate te maken moet hebben met het feit dat dit een 'relatief
>>kleinere boîte' is.
>>
>>Akkoord of niet?
>>
>>
>
>Yep. De syteembeherders zitten zelf ook wel aan de telefoon. De afstand
>tussen de helpdesk en de systeembeheerders is dan heel veel kleiner.
>Normaal ook. Als daar iemand even wat vraagd, krijgen ze gewoon
>antwoord.
>
>Stel dat alle helpdeskers bij een grotere provider bijiemand van
>systeembeheer komt vragen om wat extra uitleg, dan mag je blij zijn als
>de computers nog aanstaan. (Opsturen van: Dat zullen ze dan wel bij X of
>Y doen kun je achterwege laten)
>
>
>
>>Hun roots (wat België betreft, en als ik goed ingelicht ben) zijn denk
>>ik ook tekenend.
>>
>>
>
>Je moet de roots in Nederland eens nagaan. Dat is nog wel een pak
>serieuzer. Zegt de naam hacktic je iets?
>
>Ze zijn door KPN overgenomen, maar hebben het zo kunnen afdwingen dat ze
>niet mogen opgenomen worden in de rest van de providers (lees PI in
>Nederland, die toch al wat providers heeft opgeslokt)
>
>Verder zijn ze ook zeer bekend bij het gerecht, wegens het juist niet of
>juist wel vrijgeven en/of doorgeven van gegevens. Dit om discussies op
>gang te trekken.
>
>
>
Goed om te weten.

--
B. Mercier
<URL:http://users.kbc.skynet.be/fi001005>
<URL:http://web.wanadoo.be/b.mercier>

JanC wrote:

> houghi <houghi@houghi.org> schreef:
>
>>> Ik denk dat als een bedrijf als XS4ALL een betere service geeft, dit
>>> in grote mate te maken moet hebben met het feit dat dit een
>>> 'relatief kleinere boîte' is.
>>>
>>> Akkoord of niet?
>>
>> Yep. De syteembeherders zitten zelf ook wel aan de telefoon. De
>> afstand tussen de helpdesk en de systeembeheerders is dan heel veel
>> kleiner. Normaal ook. Als daar iemand even wat vraagd, krijgen ze
>> gewoon antwoord.
>>
>> Stel dat alle helpdeskers bij een grotere provider bijiemand van
>> systeembeheer komt vragen om wat extra uitleg, dan mag je blij zijn
>> als de computers nog aanstaan.
>
> Dat is op te lossen door meer systeembeheerders aan te nemen, en de
> zon ontstane reserve in te zetten "naast" de helpdesk...
>

Ik denk niet dat die systeembeheerders een functie op de helpdesk
ambieren. Gaat je niet lukken dus.

EJ
--
Remove the obvious part (including the dot) for my email address.
http://www.vanwesten.net for examples of ipf and pf.

JanC wrote:
>> Stel dat alle helpdeskers bij een grotere provider bijiemand van
>> systeembeheer komt vragen om wat extra uitleg, dan mag je blij zijn als
>> de computers nog aanstaan.
>
> Dat is op te lossen door meer systeembeheerders aan te nemen, en de zon
> ontstane reserve in te zetten "naast" de helpdesk...

Wat nog beter is is om alleen systeembeheerders aan de telefoon te zetten.
Helaas willen de mensen goedkoop Internet hebben en dan wordt het lastig
als je een paar honderd sysadmins moet aanstellen die 95% van hun tijd
moeten verdoen met het beantwoorden hoe je een email moet versturen.

Bij grotere helpdesken krijg je automatisch vervlakking. De reden is het
zelfde als die van fast food ketens. Het moet altijd en overal het
zelfde zijn, zodat de mensen weten wat ze kunnen verwachten.

Fast food ketens kijken dan ook wat hun beste laagste kwaliteit is en
zorgen er voor dat die overal zo is.

Het zelfde gebeurd bij grotere helpdesken. Stel ik bel met een vraag
over een Linuxprobleem en de persoon aan de andere kant helpt me om mijn
bak helemaal te configureren. Duurt wel twee uur, maar ik ben helemaal
happy.

Ik vertel dat hier vrolijk en iemand anders belt met het zelfde
probleem. De persoon die mij geholpen heeft moet je een uur of twee op
wachten, aangezien hij net ioemand anders aan het helpen was, of hij is
er niet en je kan niet geholpen worden.

Jou idee is dan niet dat ze toch hun best gedaan hebben, jou idee is dat
die helpdesk vreselijk slecht is. Je belt mischien wel tien keer terug
om die ene persoon te pakken te krijgen. Jij dus zwaar gefrustreeds.

Vandaar dat het eenvoudiger is om die support niet te geven en je gewoon
aan strikte afspraken te houden.

Heb je nog de standaard vragen. Met een goed script ondervang je daar zo
een 80-95% mee. Even de testen die je denk ik moet doorlopen:
v.b. de persoon kan geen mail ontvangen

Is de account nog actief
Kan de persoon een verbinding maken
Kan de persoon tracen of pingen
Kan de persoon mail versturen
Kan de persoon telnetten naar zijn mailbox
Zit er mail in zijn mailbox
Zijn de instellingen goed.

Je ziet dat ik pas bij de laatste stap terecht kom bij wat de beller
denkt dat echt met het probleem te maken heeft. De reactie van de beller
is dan: die weten echt van niets, ik had dat allemaal verteld en na pas
5 minuten komen ze er achter wat ik ze al de hele tijd vertel.

Stel nu dat er een probleem is met de mailserver en dit niet doorgegeven
is, dan zal dit ontdenkt worden bij het teletten naar de mailbox.

Dit is in ieder geval de manier waarop ik mijn emailproblemen check.
(OK, stap 1 kan ik alleen maar raden)

Indien je dus een helpdesk hebt met mensen die enkel maar zo werken
zullen er ongetwijfeld mensen tussen zitten die niet direkt geholpen
zijn. Jammer, dat is de prijs van de roem.

Ik zeg zeker niet dat alle helpdesken zo werken, aangezien ik er geebn
ervaring mee heb. Ik zie wel hier vaak een heleboel geroep van 'ze zijn
slecht' zonder het gehele verhaal te horen en misnstens een verdraaide
versie.
--
houghi http://www.houghi.org/jargon
It's people. Source code is made out of people! They're making our source out
of people. Next thing they'll be breeding us like cattle for code. You've
gotta tell them. You've gotta tell them!

erik wrote:
> Ik denk niet dat die systeembeheerders een functie op de helpdesk
> ambieren. Gaat je niet lukken dus.

Als je genoeg betaald wel hoor. Betaal ze gewoon drie keer zo veel als
ze nu hebben en je zal zien dat je volk hebt. Soms zou het niet eens
onverstandig zijn om zo iemand verplicht een paar dagen per maand er
neer te zetten. :-)

--
houghi http://www.houghi.org/jargon
It's people. Source code is made out of people! They're making our source out
of people. Next thing they'll be breeding us like cattle for code. You've
gotta tell them. You've gotta tell them!

houghi wrote:

> erik wrote:
>> Ik denk niet dat die systeembeheerders een functie op de helpdesk
>> ambieren. Gaat je niet lukken dus.
>
> Als je genoeg betaald wel hoor. Betaal ze gewoon drie keer zo veel als
> ze nu hebben en je zal zien dat je volk hebt. Soms zou het niet eens
> onverstandig zijn om zo iemand verplicht een paar dagen per maand er
> neer te zetten. :-)
>

Waar denk je dat budget vandaan te halen? Vergeet niet dat (goede) unix
admins nu al veel verdienen. Bovendien hebben de meesten al een derde
lijns support functie, en _helemaal_ geen zin om helldeskje te spelen.

EJ
--
Remove the obvious part (including the dot) for my email address.
http://www.vanwesten.net for examples of ipf and pf.

houghi <houghi@houghi.org> schreef:

> JanC wrote:
>>> Stel dat alle helpdeskers bij een grotere provider bijiemand van
>>> systeembeheer komt vragen om wat extra uitleg, dan mag je blij zijn als
>>> de computers nog aanstaan.
>>
>> Dat is op te lossen door meer systeembeheerders aan te nemen, en de zon
>> ontstane reserve in te zetten "naast" de helpdesk...

> Wat nog beter is is om alleen systeembeheerders aan de telefoon te
> zetten. Helaas willen de mensen goedkoop Internet hebben en dan wordt
> het lastig als je een paar honderd sysadmins moet aanstellen die 95%
> van hun tijd moeten verdoen met het beantwoorden hoe je een email moet
> versturen.

Dat *dat* niet betaalbaar is, snap ik ook. ;-)

Ik zie het eerder als een buurtrol voor de sysadmins als (hulp bij) de 3e
(of 4e ?) lijns support. Als er ergens aan gewerkt wordt zullen die dat
veel rapper weten/doorhebben.

> Bij grotere helpdesken krijg je automatisch vervlakking. De reden is
> het zelfde als die van fast food ketens. Het moet altijd en overal het
> zelfde zijn, zodat de mensen weten wat ze kunnen verwachten.
>
> Fast food ketens kijken dan ook wat hun beste laagste kwaliteit is en
> zorgen er voor dat die overal zo is.

Sommige ketens kunnen die kwaliteit echter op een aanvaardbaar niveau (of
zelfs meer dan dat) houden, terwijl je bij anderen je bord halfleeg
achterlaat. En het zijn niet altijd duurste die het beste zijn...

> Het zelfde gebeurd bij grotere helpdesken. Stel ik bel met een vraag
> over een Linuxprobleem en de persoon aan de andere kant helpt me om
> mijn bak helemaal te configureren. Duurt wel twee uur, maar ik ben
> helemaal happy.
>
> Ik vertel dat hier vrolijk en iemand anders belt met het zelfde
> probleem. De persoon die mij geholpen heeft moet je een uur of twee op
> wachten, aangezien hij net ioemand anders aan het helpen was, of hij
> is er niet en je kan niet geholpen worden.
>
> Jou idee is dan niet dat ze toch hun best gedaan hebben, jou idee is
> dat die helpdesk vreselijk slecht is. Je belt mischien wel tien keer
> terug om die ene persoon te pakken te krijgen. Jij dus zwaar
> gefrustreeds.

Als ik met een ingewikkeld en/of weinig voorkomend probleem bel, verwacht
ik zeker niet dat een helpdesk dat meteen kan beantwoorden. Maar als je
een elementaire vraag stelt waarvan het antwoord al 2 jaar duidelijk op de
site staat, en ze weten/vinden het nog niet, dan is er iets grondig fout
IMNSHO... :-p

> Heb je nog de standaard vragen. Met een goed script ondervang je daar
> zo een 80-95% mee. Even de testen die je denk ik moet doorlopen:
> v.b. de persoon kan geen mail ontvangen
>
> Is de account nog actief
> Kan de persoon een verbinding maken
> Kan de persoon tracen of pingen
> Kan de persoon mail versturen
> Kan de persoon telnetten naar zijn mailbox
> Zit er mail in zijn mailbox
> Zijn de instellingen goed.
>
> Je ziet dat ik pas bij de laatste stap terecht kom bij wat de beller
> denkt dat echt met het probleem te maken heeft. De reactie van de
> beller is dan: die weten echt van niets, ik had dat allemaal verteld
> en na pas 5 minuten komen ze er achter wat ik ze al de hele tijd
> vertel.

Zolang die helpdesker die vragen niet begint te stellen nadat je hem de
antwoorden erop al gaf tijdens je uitleg van het probleem...

> Stel nu dat er een probleem is met de mailserver en dit niet
> doorgegeven is, dan zal dit ontdenkt worden bij het teletten naar de
> mailbox.

En hopelijk wordt dat dan doorgegeven aan de sysadmins *en* aan de rest van
de helpdesk, zodat de volgende 20 bellers met dat probleem ook geen 20
minuten aan de lijn moeten hangen & onnodige kosten maken.

> Dit is in ieder geval de manier waarop ik mijn emailproblemen check.
> (OK, stap 1 kan ik alleen maar raden)

Zoiets doe ik ook ja, behalve dat telnetten, daar zijn andere oplossingen
voor... :-)

--
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9

erik wrote:
> Waar denk je dat budget vandaan te halen? Vergeet niet dat (goede) unix
> admins nu al veel verdienen. Bovendien hebben de meesten al een derde
> lijns support functie, en _helemaal_ geen zin om helldeskje te spelen.

Ik ben er van overtuigd dat de gebruikers in deze groep geen enkel
probleem hebben om dat te betalen. <proest>

--
houghi
> How to ask questions on Usenet :
http://www.houghi.org/question
Take a look and pass the word.

houghi wrote:
> JanC wrote:

[stappenplan]
>>>Dit is in ieder geval de manier waarop ik mijn emailproblemen check.
>>>(OK, stap 1 kan ik alleen maar raden)
>>
>>Zoiets doe ik ook ja, behalve dat telnetten, daar zijn andere oplossingen
>>voor... :-)
>
>
> Wat gebruik jij dan om te zien of de pop3 of SMTP server reageerd?
> Gewoon intresse hoor. De reden dat ik het gebruik, na het bevestigen dat
> ik een verbinding heb, dat wil zeggen een trace op IP niveau, is om er
> zo weinig mogenlijk tussen te hebben. Telnet op de juist poort geeft mij
> over het algemeen wel duidelijke informatie over wat er fout of goed
> gaat. :-)
>

Ik zou in iedergeval zelf telnetten naar de POP server, de (gemiddelde)
klant vertrouw ik dit niet toe.
Verder laat ik de klant zelf zijn verhaal doen en aan de hand van zijn
instellingen en foutmeldingen stel ik vragen.

Groeten, Jan

--
/"\ ASCII Ribbon Campaign
\ / No HTML in mail or news!
X
/ \ Dutch Security Information Network: http://www.dsinet.org