Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Education Open Source Windows IT Linux

Ask Slashdot: Herding Cats, Aging Systems? 158

An anonymous reader writes: I've recently started a job at a medium-sized enterprise in the UK. They claimed to be an advocate of open-source. The job was advertised as a Linux sys-admin. I've been in the role a short while and the systems right across the business are end-of-life: lots of XP and 2003 servers, a handful of LAMP web servers, and a large IT department with almost no skills in the technologies on site. Most boxes have the default password still. As a senior techie, I've been tasked with helping bring the skillset of the rest of the staff up. Where would you start, given that most of the kit is EoL?
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Herding Cats, Aging Systems?

Comments Filter:
  • by Chris Mattern ( 191822 ) on Monday September 21, 2015 @01:44PM (#50567925)

    That's the most obvious thing. Bring in supported systems and train them in those systems as you deploy them.

    • by Archangel Michael ( 180766 ) on Monday September 21, 2015 @02:11PM (#50568175) Journal

      Before you bring in supported systems, you have to have a budget. Without a budget delineated, the rest of the decision making process is pure insanity.

      My first response is, estimate what the "golden" cost will be, and quadruple it. They will cut it in half, and it will cost you twice what you think it will, and you'll end up with an excellent system that is designed well and built right.

      If you need "enterprise" grade systems, make sure that you are identifying the vendors in the space and calculate budget accordingly. And remember, vendors lie.

      • by King_TJ ( 85913 )

        This is great advice.... If this place is anything like a couple of them I've seen before though? They likely decided to become primarily a "Linux shop" in the first place because they were unwilling to spend much on I.T. -- and somewhere along the line, staff deployed Linux as a way to keep old/obsolete hardware functional.

        Assuming you can get some kind of workable I.T. budget in place, I think you want to start by analyzing what's exactly going on, on the server-side of things. Windows Server 2003 still

        • If you can't get a real IT budget, then all the Linux Wizardry isn't going to solve any problems. I have a phrase I use, "Good IT is expensive. Bad IT is costly".

          I've seen people "cheap out" trying to save a buck, only to lose their proverbial shirt in the process. It isn't worth it. It isn't worth it to work there, it isn't worth it to be a wizard for people who do not value IT.

        • If this place is anything like a couple of them I've seen before though? They likely decided to become primarily a "Linux shop" in the first place because they were unwilling to spend much on I.T. -- and somewhere along the line, staff deployed Linux as a way to keep old/obsolete hardware functional.

          This may be a valid approach if there are no Windows-only applications that are not easily replaced. But that is something you need to find out as soon as possible. IMHO that will make the difference between being able to switch to Linux in the short run and looking at a long transition period.

          For the City of Munich, switching to Linux took several years because they had lots of old applications on Windows for which there were no Linux equivalents.

      • I would say to bring in a couple of new systems first right away. Their eventual use will be testing. Use them to train the staff and test the new applications and determine capacity. THEN you can whip out the budget spreadsheet.

      • If they won't give you a budget and respond 'come to us with purchases and we will approve them on a case by case basis' then 'run away'.

        That is how they got to where they are.

      • by jrumney ( 197329 )

        Before you bring in supported systems, you have to have a budget.

        LOL. Why do you think they are advocates of open source?

    • Nuke it from orbit.

      It's the only way to be sure.

  • Go Virtual (Score:5, Insightful)

    by BDMcGrew ( 4197513 ) on Monday September 21, 2015 @01:46PM (#50567939)
    Well, your question leaves out a lot of details but from what you've said so far, look at getting some new hardware in there and start virtualizing some of the the EoL systems. This will provide you an upgrade path for existing systems and a snapshot'd point of restore in the event of a failure.
    • This.

      Getting things in a state that they're repeatable is step one and it very much sounds like you dont have that. Using a combination of VM and deployment technologies (like puppet) will both give you a safe sandbox to work in and careful change management. Once you have that the rest should fall into place much easier (disaster recovery, upgrade management, etc are much simpler).

      • by rwa2 ( 4391 ) * on Monday September 21, 2015 @03:09PM (#50568611) Homepage Journal

        Yep, Virtualize all the things was the mantra ten years ago, and still applies well today. Get everyone smart on using vagrant and VirtualBox (better yet VMware or even libvirt-kvm if you can get them to run Linux on the bare metal), and start imaging all of those legacy servers in your sandbox VMs. Build a cluster of VM servers to migrate to. Set up load balancers and test failover and rollback deploys. Set up Jenkins or Rundeck to do and log all of the actual work, and a peer review system for checkins from Github. Implement change management on a ticketing system such as Redmine or get them to pay for Jira. Set up a kanban board in Trello or Jira and coordinate everyone via HipChat or Hangouts or Skype, preferably all three. Plus the Lync people, you'll need a separate Jabberd deployment to tie those people in. Set up a monitoring system like Icinga2 and write alert plugins to HipChat and PagerDuty. That will help with backend alerts, but you'll want frontend user flow testing too so sign up for AlertSite and train your UAT people to code up their flows in the Firefox plugin. The tests will put a lot of load on your systems, though, so invest in some application performance monitoring on your toolchain like NewRelic or AppDynamics to help identify where your performance bottlenecks lie. This is a good time to migrate everything to OpsCode Chef so you can automate all of your unit testing and integration testing to prevent regressions. There are still some gaps in what Chef can accomplish with some expediency, though, so better also set up Ansible to take care of doing the actual work while the test-kitchens are running through the Continuous Integration / Continuous Delivery pipeline. Spend a good bit of time automating your CMDB tool too so you can report on all of the discrepancies that get by both Chef and Ansible. At this point Splunk is getting kinda expensive, so have a team build up an ELK stack and deploy to a dozen instances on AWS. Oh, you need a dev environment for that too, since that one time that innocuous checkin broke everything, so make that 2 dozen instances. Graphite would be very useful too, if you had someone dedicated to making dashboards for it. But someone else threw up a Dasher page over a weekend and that displayed enough of a high-level view on the workplace monitor to make the execs happy without troubling them with the actual details of things that were broken. That person got promoted and then left the company, but the dashboard page still looks good and green, so we'll leave it running for now. Except at some point a RabbitMQ feeding the ELK stack used by the Dasher page somewhere choked on something being fed to the the log pipeline by carrotd, so you better go digging for that somewhere, since the execs have a demo coming up this week and they'd really like to show that display to depict what an up-to-the-minute decision-making capability they have, but they don't want to show the Icinga2 monitor because there's too much red and amber junk on it from transient test systems that can't use the test Icinga2 instance for some weird networking issue. That could be addressed by migrating your dev environments to docker containers so everything can run within the same VM host, then figure out whether you want to orchestrate them using CoreOS or Kubernetes or swarm or fleet along with the appropriate OpenFlow network definitions, but this isn't authorized to deploy the same way to production yet, so just hang tight for now, OK? Around this time, you should be ready to tackle the migration of your services to systemd.

    • Re:Go Virtual (Score:5, Insightful)

      by ShanghaiBill ( 739463 ) on Monday September 21, 2015 @02:24PM (#50568281)

      Well, your question leaves out a lot of details

      The most important left out details are about politics, not technology. Do you have the support of top management? How powerful are the people that are opposed to your project? There are people that will actively work to sabotage your efforts, and use you as a scapegoat for everything that goes wrong. How are you planning to deal with that?

      Since you are the "new guy" trying to change things that you don't understand, you didn't even mention end-user applications, and you seem to be more interested in OSS-evangelism than supporting your users and helping them get their job done, my prediction is that you are going to be out of a job in less than six months.

      • Do you have the support of top management?

        if the stuff is really as old as he says it is, they must already be experiencing some hardware failures. it's not too hard to convince a money guy that a dead computer means no revenue.

    • Yup. Virtualization will transform the whole department in a short amount of time, and getting training for it is straightforward.

    • You need to have at least three hardware servers, all with lots of memory and disk, so you can have a primary and backup for production use and another for IT infrastructure development. If you're doing both VMware and OpenStack, which is not a bad position to take, you really need 5, two per hypervisor plus a spare.
      Otherwise you're going to be spending your time keeping your Shiny New Virtualization Platform up to date, instead of spending it Virtualizing Old Non-Shiny Stuff, which is what you should be d

  • by Anonymous Coward on Monday September 21, 2015 @01:46PM (#50567943)

    No guns, no knives... do you pussies still get rope or are you going to have to find a tall building to jump off instead?

  • You need to start a training program. If the current workers feel uncomfortable in the new technologies, the will oppose you every step of the way (though they won't say why). If they feel comfortable in the new technologies, they will push you faster in the adoption.

    If a team has been working on a lousy codebase, your first priority should be to teach them to do better. You can try cleaning things up, but they will make messes faster than you can clean. You need to find a way to teach them to at least no
    • Hell, of they don't have skills in XP and 2003, it's either train or hire new. Those are legacy tech, your staff should be nailing these now.

      And if they can get control of the existing tech, they have a chance at mastering the new. If they can't even handle the old, well, a new crew is in your future.

  • Show them the risks (Score:5, Interesting)

    by Tool Man ( 9826 ) on Monday September 21, 2015 @01:49PM (#50567973)

    I don't know your organization's level of risk tolerance, but getting them to pay for one of the following would be an eye-opener:
    - A vulnerability assessment will show a sea of red for the unsupported platforms. Maybe that'll be sufficient to convince them that it's time to upgrade (and train up on new stuff).
    - A penetration test will take those same vulnerabilities, and combine it with attempting to use those vulnerabilities to see what they could get. The difference is in trying to use those issues, and turn them into "oh SHIT" screen shots in the report. It's the difference between "someone could theoretically do X" and "someone just did X, and documented it all for your edification."

    On the latter engagements, especially with the dreadfully old stuff, it is quite enlightening to include those screen shots that show how I've added new users, logged in with them, and used them to poke yet more systems I couldn't reach from the starting point. The under-educated staff would only help things if social engineering was in scope too.

  • Running? (Score:5, Insightful)

    by gstoddart ( 321705 ) on Monday September 21, 2015 @01:49PM (#50567975) Homepage

    As a senior techie, I've been tasked with helping bring the skillset of the rest of the staff up. Where would you start, given that most of the kit is EoL?

    Well, you have 3 main choices:

    1) Try to fix it and succeed
    2) Try to fix it and fail
    3) Run like hell

    You won't be able to force the rest of the staff to bring up their skillset. Management has clearly left it to rot on the vine for a very long time. And, by the sounds of it, they don't know what they've even got.

    A large IT department with no skills with the technologies on site? What exactly is that large IT department doing for this company? If you have a bunch of people with no skillsets with the technology they have ... then what skillsets do they have, and how is it helping you?

    Without more detail, I'm hearing "Hi, I've just joined a company with a terrible IT department, how do I fix that?" Who let it get into such a bad state? Because if they're still around, no way in hell you'll ever fix it.

    • Re:Running? (Score:5, Insightful)

      by TWX ( 665546 ) on Monday September 21, 2015 @02:07PM (#50568135)
      Yep. If you're not in-charge and able to make the tough calls (ie, figuring out who's actually supporting important stuff, who's not, and making the decisions about who gets a chance to migrate to something new and who needs to take their skillset elsewhere) then you're probably not going to make the difference that you want to make or that your superiors somehow expect.

      What I can say, from experience, is that you need to actually learn how things are working now before you start making changes. I've had bosses brought in from the outside that thought they were gods' gift to the IT world that decided to try to remake the organization in their own image, only be be fired less than a year later because they pissed off all of the existing IT staff such that the boss got no results, and pissed off the users by failing to maintain existing workflow such that the users' jobs became much harder or required lots of direct assistance.

      Learn what's there, why it's there, and understand that most decisions were made as a reaction to something prompting it to be necessary. Change what can be changed in a sane way, but don't take personal offense to anything as it is now as there are probably good reasons why it is the way it is. If you come in with the attitude that you can rip out everything without a care, you'll find suddenly that no staff will bother to warn you of the pitfalls in front of you that they're all well aware of, and you, not them, will be the one with egg on your face when it breaks because it was your decision to change it.
      • I've had bosses brought in from the outside that thought they were gods' gift to the IT world that decided to try to remake the organization in their own image, only be be fired less than a year later because they pissed off all of the existing IT staff such that the boss got no results

        I'm going to say if you have a large IT organization which has no skills in the technologies you actually have ... then pissing off your IT department should be your goal, and if that doesn't work move to laying them off.

        Yes,

        • Re:Running? (Score:5, Insightful)

          by TWX ( 665546 ) on Monday September 21, 2015 @02:27PM (#50568309)
          The article submitter made it clear that he's new. He very well may not understand the workflow and who actually knows how to take care of what. He needs to learn that before he can start making changes, or he, not the existing staff, will be the one blamed when everything goes wrong.

          IT attracts a fair amount of introverts. It's likely that a lot of his staff are playing their cards close to their chest because that's what they're simply used to doing. It's also possible that they themselves wanted to make changes but were not given the budget needed to do so, so legacy systems continue to be used. It could also be that a few incompetent people in key positions have gummed-up the whole works.

          Do you think that anyone wants to be stuck with ancient garbage if there's something newer that actually demonstrably works better? Most of the time the decisions that hold back the IT department are made either by IT management or by those outside of the IT department.
          • Well, my general observations are:

            1) The number of sides to a story is proportional to the square of the number of people.
            2) There is a very small amount of information in TFS, so we have very little facts.
            3) There exist organizations in which people have been keeping their head down and their mouth shut for years.
            4) People have stuck with ancient garbage many times if it's the ancient garbage they know best.

            My ability to determine if the poster has an accurate view of his situation is precisely zero.

            Th

            • Re:Running? (Score:4, Insightful)

              by FranTaylor ( 164577 ) on Monday September 21, 2015 @03:58PM (#50569001)

              This sounds like a highly dysfunctional environment

              Mechanical-type people are usually pretty horrified by the short lifespans of computers. They are used to dealing with things like turret lathes and drill presses that can handle 50 years of continuous use. It could be a perfectly natural reaction.

    • I've worked a contract once that sound just like this, but rather there was so much turnaround there was a constant brain-drain. Crazy old stuff. After rolling out, "Your stuff is going break and you'll loose all your data forever" the manager said that would be OK because he wasn't being allocated the funds he needed to fix it. I kept things together the best I could but eventually realized I was being set up for failure. I was going to be the scapegoat. So I updated my resume and noped the heck out o

      • I kept things together the best I could but eventually realized I was being set up for failure. I was going to be the scapegoat.

        The only things you can do in that situation are:

        1) run like hell
        2) document all of your concerns so they can't blame you when it blows up

        But then if it ever comes to having to prove how you told them so, you'll be wondering why you didn't just run like hell in the first place, because at that point you've wasted your time and have been tainted by the project anyway as the ones r

  • Seriously. If this is how they're running their operation to this day, chances are its not just harmless, easily washed-away naivety that is keeping everything so poorly organized and insecure. Chances are you're going to find this out the hard way though, and they'll mysteriously get instantaneously far less apparently incompetent when it comes to finding ways to get you fired first.

    • by plopez ( 54068 )

      +1

      Bring in contractors slowly as in "They will be helping with the migrations, but regular staff will act as backups on weekends and holidays". Anyone that shows a willingness to change should be kept. Anyone who doesn't should either be fired or find an unpleasant job for them. As time continues use contractors to replace any staff that leaves. But you need to deal with personnel issues first and that usually comes down to firing people, getting them to leave, or someone dying.

    • I think is what management has in mind already. Notice that he's being asked to document the skills people need. He's been told this is because people will be TRAINED to this level, but it's more likely that other people that already have the skills will be HIRED/CONTRACTED with money freed up by letting the deadwood go.

  • I know it sounds obvious, but I would simply do what they are asking you to do - educate users, etc.

    You could mention the fact that their equipment/software is obsolete. From my experience, I would probably mention it but not push it.

    The reason is that most companies have their own way of doing things. Even if you have a better way of doing it (and you probably do!), there is nothing wrong with making suggestions. But pushing your suggestions onto management (or whoever) - even if you mean well - w
  • a large IT department with almost no skills in the technologies on site

    No skills? Then what is it that they do all day? I suspect that your IT department has been the dumping ground for employees that can't just be gotten rid of. In other words; politically connected. I've been there and tried to deal with that. And in my opinion, it can't be done by someone without serious seniority.

    You could try introducing training programs for the target architecture. And some of the motivated staff will avail themselves of this. But be prepared to run across a few people who refuse and i

  • by Anonymous Coward

    Hmm, if there are legacies, i would advise the following.

    1. virtualize whatever you can.
    2. remove the oses which are no longer supported by the vendor MSFT...2003/xp..because of security issues.
    3. get a list from business of all the critical system. There will need to create a roadmap at this stage for migration.
    4. in the mean time. start working / training the team on open source, specifically for (1) as a virtual platform.
    5. start planning (3), by training people in the direction to be...

  • Clean it up (Score:2, Insightful)

    by Anonymous Coward

    Kill everyone. Set fire to the place. Plead insanity. When they see what you were supposed to work with, they'll believe you.

  • by i.r.id10t ( 595143 ) on Monday September 21, 2015 @01:55PM (#50568029)

    Make a map of what you have, what the main issues are with each piece, and then a plan for replacement/updating/whatever. Try to include some rough (and higher than you really think it will be) cost estimates. Then present to a boss, and get buy-in. If you don't get buy-in, start updating your CV and look for another job.

    • My guess is if the boss allowed it to get to the point that your IT department has no relevant skills ... he's going to look at the cost, squeal, and suggest you do it a different way or keep the current stuff running.

      In which case it's update your CV and run like hell.

      This sounds like a situation created by management. In which case management is likely to be unwilling to do what is actually needed to fix it.

  • by Anonymous Coward

    https://www.youtube.com/watch?v=Pk7yqlTMvp8

  • Not enough info brah (Score:4, Interesting)

    by Iamthecheese ( 1264298 ) on Monday September 21, 2015 @01:58PM (#50568049)
    It depends on how much actual authority you have, how conservative the corporate culture is, and whether there are any entrenched ways of doing things. This isn't a technical question but a political one. If you actually (as opposed to officially) have authority to tell them how to do things you need first find out how the system is working now. Maybe they didn't set up passwords because multiple departments need to connect to the same server and there's no secure password control in place. Maybe they're disorganized. Maybe they're inexperienced. These all require different activities to repair the problem.

    You mentioned EOL hardware, but you didn't say whether a migration is planned or whether the money is available for one. Obviously new hardware is a great opportunity for user training, but again there are too many unknowns here. How much extra time do the engineers have to train? How much of the existing system setup is invisibly a part of how the users interact with it?

    It sound to me like you're standing on a powder keg. The right way to deal with it is to gather information. Make benchmarks. Understand system inter-operations and use. Learn who is doing what and why. Only a fool would start declaring X and Y need to be done without taking a look around first.
  • Low Hanging Fruit (Score:5, Insightful)

    by AdelieMan ( 1688684 ) on Monday September 21, 2015 @01:59PM (#50568059)
    I would audit everything, Make a matrix of things that need to be addressed easy to hard, least significant to most, and start chipping away at it. It will take time to turn that ship around, but it will be worth it, and you will keep your sanity.
    • by bluefoxlucid ( 723572 ) on Monday September 21, 2015 @02:17PM (#50568233) Homepage Journal

      Hear hear. I would suggest not being shy of technology; I've been interested in Microsoft Project 365 integration with Sharepoint for a while, and you should definitely look at your options for project management whether they come from Microsoft, Oracle, or some no-name company that provides a fantastic and little-known product as an open-source support-contracted service. What you have there is a long program, and I suggest you get RMCProject's CAPM Exam Prep and the PMBOK if you haven't got project management skills, and spend the 3 months getting a basic grasp of all that right out of the gate.

      The primary tools you're going to want are risk management and hierarchical decomposition; however, on the scale you're talking about, full project management knowledge is going to be an outright requirement if you want to do anything resembling a competent job. You *won't* want to use the full suite of project management practices--you never want to use the full set of tools outright, but rather the ones you want, for any purpose in any field--but if that place is as big a rat hole as you say, you're going to need some accounting of what's going on.

      As the parent poster here says, you definitely need to start here:

      Make a matrix of things that need to be addressed easy to hard, least significant to most, and start chipping away at it.

      Get a list of discrete, finite, deliverable projects. Things you can put into boxes and say, "This is one thing I want to produce; it's of a nature that I can tell you what work is required, how much time it will take, and what it will cost." You'll start by examining the array of systems, breaking them down into departments and components (what do they support? What do they do for each department?), and deciding what you're replacing. Are you upgrading Windows XP with stitched-together software to Windows Server 2008, or are you transitioning to a new set of systems to solve the same problem in a different way? Get that list down.

      Each thing you want to address will be something small, finite, limited, and understood. You're replacing the groupware services--Exchange, for example; the thing that provides e-mail, calendar, and such--with an upgraded, better-implemented, or new product (exchange to Zimbra, Zimbra to Exchange, migration to a SaaS such as Google for Business or Office 365, etc.). Some things break out into phases or multiple projects, e.g.: migrating Exchange to Office 365 may involve a phase 1 of upgrading Exchange to the latest version, a phase 2 of enabling some kind of synchronization and backup that you don't have now, and a phase 3 of migrating to service; while you may find that your Zimbra installation has no back-ups because you need an enterprise backup solution, and so you can't get back-ups in until you get Bacula set up.

      Once you have your list, you can start breaking them out by hierarchical decomposition. You'll want to decompose the work [youtube.com]: each deliverable (e.g. your project, Bacula backup infrastructure, delivers a working Bacula backup infrastructure as its product) breaks out into a complete set of deliverables (e.g. project management, support services, back-up strategy design, servers, client deployment with Puppet or SCCM or Ansible, etc.), which themselves each break down further. Once your work is broken down, you hit the bottom with sets of work packages--each a deliverable--that you can understand completely; you can turn those into lists of activities and tasks to produce the deliverable.

      The same goes for risks. You want to identify everything your experience says can go wrong, and use your experience to do qualitative risk analysis--what risks are important? Then you use a procedure of assessing probability vs severity to do quantitative risk analysis. You work out how to avoid (100%), mitigate (any%), accept (0%), or transfer (buy insurance) the negative risks (threats), and how to exploit (100%), en

      • If they can't afford upgrades to newer operating systems (even with LAMP?) then they're not going to afford new solutions that require the newer operating systems as a foundation.
        • That's, of course, something you find out while examining all the shit that has to be done and all the requirements. Sometimes the business finds it can't continue; sometimes it finds it has to take certain approaches over other approaches it would prefer; and sometimes it finds budgetary priorities need to shift, when the need is sufficiently great as to interfere with the business's ability to execute its business strategy and maintain its competitive nature in its market. No sense diverting money to s

  • Although there's big money in cleaning up someone else's mess, you got to recognize a hopeless situation when you see one. Fire everyone and bring in a professional IT team to take over the operations. Or run like hell and hope that the next job isn't as bad or worse as this one.
  • Lead, Mentor, Grow (Score:5, Insightful)

    by mtippett ( 110279 ) on Monday September 21, 2015 @02:03PM (#50568097) Homepage

    You've been dropped in an environment that is legacy and probably has production problems. Use that to your advantage.

    You've been also dropped in a leadership role (not management, leadership).

    Your #1 target should be to make yourself redundant (which ironically is likely to get you promoted, it's called succession :).

    So look at doing something like identifying #1 problem (Pareto charts help). Ask for volunteers (or volunteer some people), give them the problem to solve, use whiteboards, etc to help them discover the solution. You may facilitate and provide hints to get things done. Empower and guide the people you are helping.

    Read up on https://en.wikipedia.org/wiki/... [wikipedia.org], you are likely in a #2 or #3 combination. You can help lead people to move to a #3 with leadership, with the idea to get to #1 over time (with their help).

    Of course there might be some issues that you might need to solve like EOL systems and any budget that may be needed. If the OS is old, then probably the HW is old as well. Budget for that is probably going to be your biggest issue.

  • Wanted: (Score:5, Insightful)

    by Drewdad ( 1738014 ) on Monday September 21, 2015 @02:07PM (#50568131)

    Wanted: IT Director
    Pay-scale: Entry level.

    • by Tablizer ( 95088 )

      ...with 20 years of experience in Java 9.

    • I had an interview last summer with a company last year that advertised a PC tech position for $25 per hour. The hiring manager was out when I came in for the interview and his assistant told me that position only paid $15 per hour. So I told him I wasn't interested. Since my name was similar to someone else in the company, the recruiter accidentally emailed me the salary spreadsheet for that location. All the PC techs were paid $10 per hour. If I came back in for a interview, they may have tried to brow be
    • by Anonymous Coward

      *Expands job listing*

      We're offering a chance to participate in a company that has 50 years of business success while still maintaining a start-up mentality.

      Job requirements:
      8 years COBOL
      5 years LOGO
      2 years Assembler
      6 years experience porting Windows 10 applications to our proprietary BSD-based server.

      Fluency in Old Norwegian is a plus, because we're pretty sure that the technical writer who did all the system documentation was mixing his hobby with his work.

    • I've seen a job like this re-posted several times through a recruiter for the last year. Not surprising. The irony is that by this point, if they had proper attitude, money, and support for the position in the first place, they'd probably be saving money.

  • by Anonymous Coward

    1) Start with the printer by printing copies of YOUR resume
    2) Distribute broadly
    3) Get the hell out before their stench rubs off on you

    Seriously mate, you CANNOT fix this. They will drag you down to their level.

  • If the powers that be allowed such a situation to exist, and didn't specifically hire you to change it, along with a guaranteed budget with which to accomplish the task, then it will be almost impossible for you to fix it. The fact that they essentially lied to you about your role does not bode well.

    If this is a resume building job for you then dink around the edges on things that won't require much, or any, money or many changes to the status quo. Make big talk about how you are improving things. Take ever

    • by ThorGod ( 456163 )

      tangential question - in IT is it a year that is considered the minimal amount of time before you can reasonably move on to the next thing?

      • As an IT support contractor for three or four contracting agencies, I've worked from one day to one year on a given assignment. If a contract goes sour, I wouldn't hesitate to look for a better opportunity. Non-contractors are more concerned about putting in the minimum amount of time at a job to keep their resumes looking good.
        • by ThorGod ( 456163 )

          That's my question - in full time/regular employment what's the minimal time expected to hold a position in IT?

          • Between one to three years. Most recruiters and hiring managers would like to see at least three years in each of the last three positions on a resume.
          • There is no such thing as permanent employment. Any job held less than a year gets retroactively classified as 'contract work'. Less questions that way.

            Any job held less then a month is simply left off the resume.

      • I only said one year IF this is a resume building job. If you already have plenty of skills and experience start looking for a better job NOW. Once you have that better job, just leave the crappy, short-term job off the resume.

  • And you had no idea at interview? Did you ask questions? If you did, and if they told the truth, what WAS your intended strategy?
  • Getting out quick is great advice. However, if that's not a realistic option, then level with management that it's a big job, and ask for a priority list from them.

    Make a list of things to be done, along with the reason or consequences of not doing them, give your suggested priorities (A, B, C, D, etc.) for each task, and ask management to confirm or reassign priorities.

    Often they won't want to assign priorities because that commits them to their decisions. Managers like wiggle room to blame others.

    To get

  • start (Score:4, Insightful)

    by JohnVanVliet ( 945577 ) on Monday September 21, 2015 @02:14PM (#50568207) Homepage

    -- quote--
      Where would you start,....
    ----------

    with the thermonuclear option !

    with DEFAULT passwords of "password"
    and using XP and MS 2003

    the use of DBAN has been authorized

  • >> large IT department with almost no skills in the technologies on site...As a senior techie, I've been tasked with helping bring the skillset of the rest of the staff up

    Stop right there and understand that you've been sent on a wild goose chase. You're not really going to train your existing staff - ever. Instead, what you're doing is writing the job descriptions for the outsourced personnel that your management will hire to replace the deadwood in your "large IT department" (because it's no doubt

  • You were brought on as Linux SysAdmin; you now know that the job is nothing of the sort, and getting things up to speed will require massive investments in technology, personnel, and many sleepless nights on your part, should you choose to perform this task.

    If you want to do this at all (and it sounds like you do), you need to demand a raise and quit if you don't get it.

  • Comment removed (Score:5, Insightful)

    by account_deleted ( 4530225 ) on Monday September 21, 2015 @02:22PM (#50568267)
    Comment removed based on user account deletion
  • End of Life? Dude, I'm running Cobol code that probably dates back to before you were born!

    If it does the job that's one thing. If it's all patched and up to date security-wise, you are OK. If however, the systems are constantly running at 100%, and you've got latency and throughput issues, then that's a different story.

    If nothing's getting backed up because the systems are under huge strain, then in that case you are welcome to start upgrading. In fact, you might be able to keep the same hardware and simpl

    • If it runs XP and 2003 then by definition it's unpatched.
      If the servers are ten years old and only do file shares, print server etc. I don't think the CPU is used much. Network may be entirely 100 BaseT.

      It might be the right kind of boring, and the useless team of co-workers can be hired to play special Warcraft III maps or something.

  • Take the paychecks while you can, but you need to get the hell out of there.

    The company obviously doesn't care about IT, and you almost certainly aren't going to change that. Let them rot.

  • A fire? (Score:4, Insightful)

    by onkelonkel ( 560274 ) on Monday September 21, 2015 @02:35PM (#50568377)

    Seriously, "accidentally" toss a lighted cigarette into the paper recycling bin in the server room on your way out one night. You'll be able to start fresh with the insurance money.

  • ok, saying PM will fix it is cheap but that's really the core task of project management "to devise a plan"

    But a specific plan with goals needs to be based on an analysis of the environment you are actually in and you did the first steps, you tried to describe the environment.

    medium-sized enterprise, UK
    Ok, you're in the UK and have access to a solid workers pool of skilled IT, also available by contract workers.

    Think about getting an aide, nothing is worse than a project manager that looses oversight!

    They c

  • You're in for a wild ride..
    1. Meeting with senior management
    2. powerpoint presentation on just how fucked they really are, complete with flowcharts and LOL gifs
    3. preview development plan on getting everything current
    4. write number on piece of paper of what it would take to get the job done
    5. pass it around, watch them squirm
    6. go-pro camera
    7. post results
    Joking aside, given the current team doesn't understand the current technology, you'll have a much easier time getting them used to the new te
  • XP, LAMP, 2003 servers, all of those things are spiffy new systems to us. Almost all of my job is trying to get old PDP, MODCOMP and DOS systems into the modern era of things like Windows NT or (Jobs forbid!) linux. Sites with truly aging systems are rarely willing to spend anything like what it would cost to really bring what they have up-to-date and they often have good reasons -- how many security issues do you hear about those aged systems vs [recently] modernized ones?

    Of course, it also help to keep al

  • Hmmm, if the country weren't incorrect, I'd say you work where I do. :-) I'm in a similar boat -- lots of old stuff, lots of "don't fix what ain't broke," etc. Change does happen, but it's very slow compared to other places. I can give you some advice based on what I've been able to do:

    First, for all the EoL hardware -- secure funding for an appropriately sized VMWare or similar cluster, and P2V everything that doesn't absolutely, specifically require physical hardware. (That list is getting shorter and sho

    • by rwa2 ( 4391 ) *

      Good advice! Another tactic is to propose a "pilot project" to migrate just one of the "low-hanging fruit" servers to a VM... something that's not very business critical that no one important will notice if it's down for a while to work out all of the kinks. After that's done, declare success, hand the procedural documentation over to the "B-team" to complete the rest of the migration, and take a promotion on to greener pastures. Then we can entertain another exciting "How to IT?" Ask Slashdot question f

  • by advocate_one ( 662832 ) on Monday September 21, 2015 @03:07PM (#50568593)
    it's the only way to be sure...
  • Not enough details here to make informed advice try the following for a start:

    Questions. Is the company reliant on IT? What is it worth in £million? Do they care about IT enough for you to make a huge fuss and be listened to?

    If you are just a Linux admin - and they've lots of Windows admins in a huge company - you are a small cog in a large, crushing machine. If you are supposed to be bringing up their Linux skills and nothing more, do that to the best of your ability and leave.

    If your job is to trans

  • by Anonymous Coward

    Make sure that the separate firewall works, then go from there. Were your bosses thinking that a Linux admin was a Windows admin with extra skills, that the Windows skills came automatically with the Linux skills?

    Don't beat up on the geezers there for having stale skills. They might actually be OK at keeping those obsolete systems running. Some of them might be OK at getting a new system running, unless they're stuck in their ways.

  • You have an impossible task. Rejuvenate your CV, and find your next job.
    Seriously though, start with a budget. Until you can secure funds you cannot do anything and the budget will tend to direct what you can accomplish next. Once you have cash, find the oldest piece of hardware in operation and start with that one. You will have more failures based on hardware than you will based on unpatched OS's. Disks are your primary concern in this realm.
    Second, after you've completed a few of the more horrendous

  • No company could pay me enough money to willingly take on that headache. I'd likely end up in a mental institution ....
  • "As a senior techie, I've been tasked with helping bring the skillset of the rest of the staff up. Where would you start, given that most of the kit is EoL?

    Sounds like they expect you to function as an unpaid tutor as well as your duties as sys-admin. Find out why the last fella left and how long he was in the job. Start looking for another job.
  • Sounds like you are a systems admin, and you want to be an engineer. You need to talk to the CIO/CTO. This problem pre-dates your tenure.

    It's not the system that determines the solution, it's the vendor. So whatever it is they do you are already off to a bad start.

    What budget to they have to replace their solution? Where are they in the market? How can you monetize this solution if they haven't already budgeted for it...

    In my not so humble opinion your question (and more importantly how you are asking it) w

  • You need to hire a couple-three top people who can migrate the systems. Migration from EOL systems is a headache, requiring plenty of debugging. I've been in those situations, and you need people who can do that task.

  • You've described existing infrastructure, but the important thing for the business is applications. That's the thing they need, every day. I worked in an infrastructure group in a UK investment bank, the only time they notice what you do, is when it snarls up or fails.

    For example, there was a recent thread discussing whether Access has an open-source equivalent, IMO it doesn't really. So, if they use a lot of Access that will constrain upgrade path UNLESS they're prepared to take some risks and spend to
  • I do this for a living, but I will give you some free advice just this once.

    Given your summary, the only thing relevant is probably this:

    [...] a large IT department with almost no skills in the technologies on site. [...]

    As an experienced career consultant with many years experience I can read between the lines and glean information that every other person who has replied to this thread seems to have missed. Essentially it boils down to this: every single employee in that large IT department started out in your job. Lots of people in your position didn't make it into the IT department beca

  • OK, so this isn't just an excuse to post "Beowulf Cluster!" on /. one last time, but it probably sounds like it... :-)

    What you really want to do is start using cloud services like DigitalOcean or (if you must) AWS. In this day and age you can pull more computing power out of the damn _air_ than currently exists in your building. This isn't "going OSS", this is a space where open source tools like Linux, GIT, Ansible, cassandra and other are simple necessities because nothing else can do the job. Licences ar

  • I'd focus on the people side - figure out what who you're going to get rid of, who you can work with, and build good habits of working well with them while you hold down the fort - feel out your first few changes to see what kinds of resistance you get from humans (and from technology). How that goes will give you a feel for the possibilities of larger change.

Work is the crab grass in the lawn of life. -- Schulz

Working...