Entries tagged as linux
Wednesday, January 26. 2011
It seems like sooner or later everyone ends up writing about interviewing. “My favourite questions” are one of those topics that pop up again and again, but I am so often bemused by what those questions are.
Take a recent StackOverflow query; “What are your favourite questions for a senior Unix admin?”. The responses elicited were almost entirely of the “swallow the man pages” or “trick questions I know” or worse yet “simple stuff I can Google” variety.
Folks, whether or not I remember how to use ldd or strace, or remember that it’s truss on Solaris, not strace, does not make me a senior SA, and if you think it makes you one, I pray for the sake of your ego I never interview you. Those are questions I’d expect that a junior would either know already, or be able to find given a few minutes with the search engine of their choice. Even in the dim dark days before ubiquitous workplace Internet access and decent search engines, one could fairly quickly find the answers with a wall of documentation or, if all else fails, telling a colleague you’ve forgotten and letting them tell you.
What does a senior SA look like to me? A senior SA is someone who solves problems. S/he understands that the role of a senior is to be able to understand the relationship between complex application layers and the systems s/he’s responsible for, so that when someone rocks up to them and says, “This critical application that makes us lots of money isn’t working, and it appears to be a slowdown with this other application it depends on running slow, but we looked at the virtualized server and we can’t work out why it’s going slow”, s/he can get on with pinpointing the fault, not raise their hands and refuse to look at it until the app and network guys prove it isn’t their problem. That’s why I ask questions that are app-centric as well as server-centric. Can a candidate trace down the stack from high-level symptoms to nail the problem? Protip: if your answer at this stage is “not my problem”, we’re done.
A senior SA can sit down with a problem they’ve never encountered before, and even if they can’t solve it, they can demonstrate that they understand the principles of problem-solving, that they know where to look, that they’ll look to the most likely indicators based on the evidence they’ve unearthed. They’ll follow a logical train of thought, and they’ll investigate things in a controlled fashion. And if all else fails, they’ll call for help and beat their head against the problem until help solves it, or they do. That’s why I ask questions that start with a simple problem statement from real-world issues that have paged me at 2 am, and see if the person in front of me attacks it the right way. The result isn’t really relevant—they don’t know my environment in detail, after all—but the methodology is priceless.
(You get bonus points if you mention, “I’d check the change logs to see what changed today” as a starting point.)
Problem solving isn’t just at the break fix level. A senior SA should be able to plan, design, think ahead, solve the bigger problems. I want to know how you work out your patching strategy, how you balance critical security fixes with regular cyclical upgrades and the desire for stable systems, how you’re going to work in with project deliverables. I want to hear your views on the best way to manage authentication. Tell me how you like to automate server deployments, how you deal with guest sprawl in virtualized environments. What information is key to your understanding of capacity planning. And virtualisation? How do you feel about it, anyway? What problems does it solve, what does it create? I don’t care if you don’t know all the answers to these questions, hell, I don’t. Can you ask me good questions when you don’t know the anwers? Can you, in short, talk to me about them intelligently?
I do not fucking care if you remember how to delete a file called ‘-rf’ from the root filesystem off the top of your head.
Monday, February 1. 2010
So yum stopped working on a couple of servers that were registered to servers with what appeared to be a login problem:
$ yum install osad
File “/usr/share/rhn/up2date_client/up2dateAuth.py”, line 217, in getLoginInfo
File “/usr/share/rhn/up2date_client/up2dateAuth.py”, line 165, in login
File “/usr/share/rhn/up2date_client/up2dateAuth.py”, line 121, in readCachedLogin
data = pickle.load(pcklAuth)
File “/usr/lib64/python2.4/pickle.py”, line 1390, in load
File “/usr/lib64/python2.4/pickle.py”, line 872, in load
A yum clean all, the usual remedy to this one... achieves nothing. The server is checking in with the Satellite server, as far as Satellite is concerned, but yum fails on pretty much any operation. Here’s the weird solution: queueing an update in the Satellite server for that box, and then running
…pulls down the update, and then yum starts working again.
Tuesday, January 26. 2010
One of the best things about attending the Linuxconf is the renewed sense of enthusiam for my field (lightly dampened yesterday by battling with @#@^#%$!^% PulseAudio, which is the worst thing to be inflicted on desktop Linux in a long time, and today on arriving home to discover a household box had literally cooked itself, likely beyond repair).
A lot of the last near-decade has, for me, seen my interest in what I do wane, damn near finished off by two years of release management. I had become, well, barely a tradesman, practically an assemblyline worker; interested in doing my job properly, but largely devooid of a vast care factor beyond that.
The last while working on zLinux has helped considerably with that, and LCA has piqued my interest mightily; I want to get back into hand-rolling Postgres releases to play with the new features, I want to play with new technologies and tools and follow their development, not just because I want to be better as a craftsman of my job, but because I can glimpse my former interest in the art of what I do; of doing a thing for itself and that alone, rather than merely because it turns a crust. On that front, LCA is a huge personal success as well as providing me with a bunch of professional value, and that’s (hopefully) a genuine improvement in the whatsit of my life.
Friday, January 22. 2010
perf superceeds operfmon and similar tools for understanding.
Continue reading "perf counters"
Thursday, January 21. 2010
Wednesday, January 20. 2010
ceph is one of those things that fills one with the kind of “gimmegimmegimme” enthusiasm.
Continue reading "Ceph"
Bharata B Rao Srivatsa Vaddagrir Vaidyanathan Srinivasan
Schedular optimisations for multicore systems. This is relatively recent work, so some of it is still pretty rough. Well, that’s Bharata’s opinion. Personally I found it like my trip to see IBM in Brisbane; really really smart people talking about something they have a deep understanding of in a very accessible way. A++ would listen to again.
Continue reading "Optimal Task Placement on Multicore Systems Using Performance Counters"
A Case Study Using ext4
Not really about the features of ext4 per se; a talk about bugs and error and problem handling and what’s required to get production-ready status, and what the challenges are.
Continue reading "Making Production Ready Filesystems"
aka The Kernel Report LCA2010
Jonathan Corbet from LWN
Organised in terms of challenges, because this will help spell out where we’ll have to do.
Continue reading "Seven Challenges for the Kernel Community"
Tuesday, February 19. 2008
That is all.
Actually, that is not all. What a painful, over-engineered non-solution to a variety of, for the most part, non-problems. And those responsible for the religious crusade of texinfo can go to hell.
That is all.
(Page 1 of 2, totaling 12 entries) » next page
Ada ada android bikes cars ceph copyright economics egroupware eve farming fatherhood feminism football french funambol gym hi-fi internet Isis Jaques java judo lca2010 lca2012 lego Lias linux maire Maire mangling language movie new zealand oracle perl phil ochs pixar postgresql question of the day racism rails Rosa snark sony-ericsson syncml sysadmin typo uk venting vignette virtualisation wave wtc bombing