Given the level of concerns, experience sharing and other reflection I've provided so far, which have been extensive, I'm going to pull back from commenting further, especially after this last share. I could be teetering on inhibiting people to share their own concerns, experiences and suggestions, which I don't want to do.
I'm going to limit my comments going forward to confirming or explaining Red Hat and, to a lesser extent, hLinux (Debian-based) support and technical specifics, when they come up. Although also understand I do not speak for Red Hat or HP any more than the IEEE or LPI for that matter. I hope my sharing so far has been insightful to a few, but I've kinda turned it into a "fire hose" at this point, which is unfair to everyone. - bjs On Friday, October 20, 2017, Bryan Smith <[email protected]> wrote: > On Friday, October 20, 2017, Alessandro Selli <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> On Wed, 18 Oct 2017 at 22:10:27 -0400 >> Bryan Smith <[email protected]> wrote: >> >> > Remember, in a multi-user solution, taking things off-line may be >> > impossible. >> >> It might be rude, far from impossible! ;-) >> >> shutdown -h 15 'Dear users, it breaks my heart informing you this server >> is >> going down in a few minutes. I understand that, being lunch-time, you will >> probably read this message too late to logout in an orderly fashion, but >> believe me it was really needed. For every inquiry about this shutdown >> ask my >> boss - he knows and he approved. Yours sincerly, your BOFH.' >> >> I understand your point, but we're talking of non-trivial sysadmanship, >> that to me goes well beyond LPIC-101 scope. > > > I'm trying to compose a response to this, and failing everytime. I > literally cannot give a tactful response here that I feel no one will not > take some offense to. > > So maybe it's better if I share my very, very biased experience ... > > 1) I've worked almost entirely in environments with SLA guarantees. A > violation causes 7+ figure financial losses, and possibly several > terminations. > > 2) Even if resolution of an issue to a problem is deferred to Level 2, any > imvestigation Level 1 would do would have to be non-impacting > > I.e., Level 1 needs to either know tools that are non-impacting, or at > least know what tools not to use > > 3) Turnover rates at Level 1 are the highest, so I am failing Level 1 if I > don't ensure they have the knowledge to prevent an SLA violation > > Now peopleay define "Level 1"differently. Here I am using "Level 1" to > refer to sysadmin operations, and not triage from a help desk script or > knowledge base. > > E.g., > 1 - syaadmin (operations) > 2 - senior sysadmin (emgineering / implementation / escalated operations) > 3 - architecture (and escalatex engineering / 2x escalated operations) > > For those that include triage/help desk, that would add +1 to the others > (level 2-4), and level 1 would be more "user" level. > > In fact, that's Red Hat GLS/Training (2-4 are sysadmin level) compared to > LPI (1-3 are sys admin level). > > - bjs > > P.S. Most on-line tools that are non-impacting are also useful off-line > too. Hence why they are taught to Level 1 sysamdins. > > > > > > > -- > > -- > Bryan J Smith - http://www.linkedin.com/in/bjsmith > E-mail: b.j.smith at ieee.org or me at bjsmith.me > > -- DISCLAIMER: _This message may have been composed on a mobile device without a physical keyboard and/or with auto-correct enabled using a limiting display that inhibits full review._ -- Bryan J Smith (bjs) http//linkedin.com/in/bjsmith b.j.smith at IEEE.org - me at bjsmith.me
_______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
