Slashdot Mirror
Ask Slashdot: What Are Some 'Best Practices' IT Should Avoid At All Costs? (cio.com)
snydeq writes: From telling everyone they're your customer to establishing a cloud strategy, Bob Lewis outlines 12 "industry best practices" that are sure to sink your company's chances of IT success: "What makes IT organizations fail? Often, it's the adoption of what's described as 'industry best practices' by people who ought to know better but don't, probably because they've never had to do the job. From establishing internal customers to instituting charge-backs to insisting on ROI, a lot of this advice looks plausible when viewed from 50,000 feet or more. Scratch the surface, however, and you begin to find these surefire recipes for IT success are often formulas for failure." What "best practices" would you add?
Just like Hillary Clinton and the IRS.
Outsource the IT to India.
ISO 9000
ITIL
TQM
CMM
You need to have to crawl before you can walk Management frameworks are for Olympic Class organizations.
Suggestion - Build your own policies, procedures, and get those in place so you know what the pain points are before you try to implement someone else's idea of what's ideal in IT.
Fred in IT
All of what is called "best practice" is doomed. When something is called "best" search for the metric. If this is not quantifiable by a number, then this cannot be a best of something. I still need to meet a so called best practice which is measurable.
None of those were best practices...
Best practices are like, "never auto-commit schema changes, always dry run them first".
I am not talking about common tools such as email servers, word processing, spreadsheet...
But software core to the operation of your business. Companies will sell you massive enterprise solutions, filled with best practices and buzzword features.
However the effort in implementing this is usually much more complex and costly than a small team of full time developers to make simple solutions to solve the problems unique to the business.
These companies selling these solutions hire a team of full time employees just to support the company. Then they charge you for the software and their time plus the profit margin. So you end up paying more for features you don't use and extras that are hacked in and barely work.
Your organization offers solutions, products or services that are unique. Why would you expect software and best processes to be the same.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
ALWAYS avoid adopting technology that you don't understand just because somebody on your staff or a salesman with some glossy sales flyer says it will be great! If your manager shows up with the idea, convinced that it's going to be the solution to all his problems and won't take your advice on the matter, update your resume....The devil is ALWAYS in the details...
There is no silver bullet... Trust me, I've looked for years... However, that doesn't mean you cannot shoot yourself in the foot with a plain old lead round.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
From bitter personal experience, trying to implement the entire ITIL manual down to the tiniest detail instead of treating it as a guideline for what might be applicable.
Case in point: my former employer had a dated-but-usable change management and helpdesk system they'd used for years. It was due for replacement. They brought in a non-IT project manager to design it. Mrs. Non-IT Project Manager proceeded to treat the ITIL guidelines as some sort of roadmap, demanding the most granular, process-laden, cumbersome, needlessly-complex system I've ever seen. It was universally reviled. Nobody understood it. Nobody was properly trained on it. Tasks that used to take hours now took days. People started working around it, not using it, in order to get even basic stuff done. The system required a complete overhaul -- this time using actual input from the people who would be using it and/or served by it -- and eventually became usable at a cost and schedule far beyond the original mandate.
Meanwhile Mrs. Non-IT Project Manager was given a raise and promoted to somewhere where she couldn't do that kind of damage again.
In the end they will lay their freedom at our feet and say to us, Make us your slaves, but feed us. - Fyodor Dostoyevsky
And blindly following banal best practices that may or may not apply in any given circumstance. In other words, learn from others, but always use you best judgement.
Avoid using Microsoft software as much as possible. Sure, your users might complain, but others are so much more secure.
This is one of those situations where the 'best practices' both look bad and are hard to get rid of because they(often) are the locally optimal approach in a situation that is unlikely to go well.
If you follow those "best practices"; you are basically doing what you can to act like a contract or outsourced IT service provider despite being an internal unit. If that's the best relationship the department can have with the rest of the company, yeah, odds are that it isn't going to go all that well. Best case, you'll be an efficient and largely inoffensive closer of tickets and deliverer of legalistic written-to-spec 'solutions'; worst cases go down from there.
However, unless you really are dreadful at this; odds are that the IT department is acting like an external contract break/fix shop because the rest of the organization views them as one; more or less irrelevant unless something has stopped the email from flowing or a specific buzzword needs implementing. Organizations that view IT as a basically homogeneous support mechanism for the status quo probably aren't going to be doing anything terribly elegant with it; but not because they are hamstrung by IT billing for helpdesk time; but because they don't really want to have IT, except the bare minimum required to keep stuff from being broken all the time.
Forced password changes every X days. This just leads to people picking really shitty passwords. At one company I worked at for a while, they mitigated this by simply doing "simple word" + month + year. TOTALLY hard to figure out!
"It's a common vocabulary/approach"...of bollocks; well done dipshits!
A directory service is good in theory but most it departements isn't competent enough to hande it, i.e. it will cost more than not using it. .
So every computer and server in the company should have separate accounts and passwords? I ask because having a common source for accounts and passwords across an enterprise (or even a small business) is one of the primary things a directory service does for you. Thinking about using Google, Facebook, or Microsoft accounts for you employees to log into company resources? Those are (outsourced) directory services as well.
Secondarily, directory services provide the ability to group users together for various permission granting. You grant rights to accounting resources to your "accountants" group and then you place your accountants in that group. When you hire a new accountant, you just put them the the group; when an accountant leaves the company or moves to a different job function, you take them out of the group. How would you accomplish this reliably without some sort of directory service?
If you are talking Microsoft's directory service (AD), you also have the ability to maintain consistent workstation configuration, which can be quite difficult without a directory service.
I believe it would cost you more in terms of time, effort, and mistakes you will make if you *don't* have a directory service.
Because if it's been delivered and it works, there will be no time to clean it up.
If there's a best practice to avoid then avoiding it becomes a best practice, and then you should avoid avoiding it. Or something.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Not gonna work in the long run. Eventually, only dudes left. Then it turns all-gay. Then you're all on Macs. Then your market falls from 90% to 5%.
therefore, buy IBM
1. Anything with rapid in it's name. Rushing stuff means it breaks. It may not break today, but it will break under heavy load when you're trying to do payroll.
2. Do It All At Once. Trying to change multiple things at the same time inevitably means you didn't understand the implications of the massive retraining, the fact that the sales force can't complete transactions fully, and the fact that the world ain't perfect like the software and hardware think it is.
3. Not having either rollbacks or testing, or cutting either or both of those. No rollback means you wiped the old server when you migrated everything. Now you have nothing. No testing means not just a few minor things will break under actual full user crush load, but that everything will break most of the time.
Here endeth the lesson.
-- Tigger warning: This post may contain tiggers! --
I had a ton of experience building web apps as a contractor. I'd see lots of projects that were structured as strict OO projects, even though they were simple web apps. The level of complexity and time and expense it takes to build a complete OO application actually ran one of the companies I worked for completely out of business. They ran out of money before they finished the application. Ignoring some of the "best practices" whitepaper garbage would've gotten their application finished in half the time.
I don't respond to AC's.
Well, I am experienced and I would say avoid over complicated directory services. Don't try to make AD and group policy do everything. You don't have to use a feature just because it exists.
Security group, distribution groups, a few group policies and a logon script covers most if not all needs. Heck, my old school logon.bat just sets some drive letters, copies a few files and sets a company standard email signature.
Automation often requires AD but I don't push it further because I know I can't trust most of the initial information I get from HR and hiring managers. SMBs tend to operate with more exceptions than rules so directory services are useful but only to the extent that the automation is helpful.
Or have very bad standards in the first place. That way, you are going to enjoy all "Web Application Worst Practices" that people can think of. I am currently assisting a customer wading thorough such a mess.
Also nice: Fire people that created and understand the application after they have finished, but before anything is documented.
And to top it off: Declare the proof-of-concept to be the final application. It is much cheaper!
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Got some inadequacy issues to deal with?
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
+1
"Wait for Service Pack 1 before deploying".
I disagree with Bob's #6, that it is a mistake to charter IT "projects."
He says:
>
The problem is that IT does not have control over something like "increase sales effectiveness." It's nice to push that as a goal and justification for a project, but all IT can be held to is "implement Salesforce.com." That is our expertise and what we can deliver. Of course you can partner with other departments, but you shouldn't commit to nebulous goals that depend on them having their shit together and excelling.
Seems to be my employer's philosophy, anyway.
"UNIX is very simple, it just needs a genius to understand its simplicity." -Dennis Ritchie
You are spot on, OP must be running less than a dozen machines if he thinks skipping a DS is intelligent in the least. Some of the worst advice I've seen on here, thanks for being a beacon of light.
Also SAP....
Truly the dumbest thing I've seen on the interwebs this year.
I spend a lot of money paying Internet trolls to trash-talk linux in public forums so that my competitors won't run it.
I believe you're right, but there is a tipping point. As with many things, working well small does not equal working well large.
An office of three people may be better off without trying to manage AD where every OU has to be customized for one person. At three hundred, that same management style will break down in a never-ending cycle of fixing dozens of issues every day that could have been avoided with group policy.
The trick is knowing when a system will save you work vs when it will cost you more. Our office is definitely better off for AD, but we're just large enough to sometimes benefit from a print server and just small enough that managing it sometimes costs us more time than it would take to manage printer resources on an individual basis.
they're colleagues. Coworkers. Not Customers. As soon as you make them customers you put everyone of your front line guys in an antagonistic position. That's because customers are where you make money. And they know it. You might appreciate them. Even like a lot of 'em. But there's always going to be tension there. And once you start offshoring (which if you're a medium+ sized company your bean counters will make you do) then all bets are off. They'll fight you tooth and nail.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
because if you hire an internal team you're paying them in your internal currency while you shuffle money about for tax dodging. That tends to be a lot of (largely imaginary) dollars. So you're spending $20 mil a year on paper and the outsources comes in with a $5 mil quote. Only problem is you're really spending about $1 mil of real dollars and suddenly you're out $4 mil and getting crappy service.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
As of NIST 800-63-3 forced password changes based solely on time interval is no longer a 'Best Practice'. Now the Best Practice is to expire passwords only when there is suspicion of account or system compromise.
Sadly it will take some time before the many organizations who copied the old best practice into their own documentation can step up to current best practice.
Truly the dumbest thing I've seen on the interwebs this year.
You must not have spent much time on the interwebs.
This all depends on the size of your organization and competency / bandwidth of your IT department.
For an organization with 10s of thousands of employees located at hundreds of sites around the world, yes, AD is priceless (if, still somewhat less than 100% up to expectation at times.)
For an organization with 10s of employees located at a single site and an IT "department" of one or two guys... ummm.... been there, done that, no, AD was NOT worth the time and apparent effort - maintaining separate passwords on the handful of servers was FAR more efficient.
If your organization isn't organized enough to use a directory service... that's your first problem.
"logon.bat". Ha. Welcome to 1995.
Windows automation doesn't require AD-- but can certainly benefit from it. Other forms of automation don't require AD at all.
From an O/S & hardware platform that's damned near bulletproof thanks to years of blood, sweat and tears to the latest, and totally untested hotness and expect shit to work out of the gate.
(Been there, done that. Recently. Really, really sucks)
Test, assess, learn, rejigger, test, assess learn then test again! Oh and don't forget to properly train those who're tasked with making this miracle happen. The RedHat sysadmin classes are huge wastes of money and time when it comes to training experienced people for that sort of migration.
Best Practice? Give the ops guys the power to tell architecture to fuck off.
"I printed something. Where's my doc?"
"Where'd you print to?"
"CVDD648b-9w"
"Oh, no, no, no. That's the printer on the 7th floor in the Houston office. You need to print to VDjddD70-%8f."
..pulls out flask, takes swig..
Ahh yes, the "we really suck, but we consistently suck, we've got the ISO 9000 cert to prove it" argument.
Yes. That's the whole point.
True story. I used to work for a company that did low-cost assembly for big vendors. Razor-thin margins, which means that the whole business depends on a highly efficient supply chain composed of other low-cost suppliers. When it came to a specific production line, a change of less than 1% in components rejection would either cause a financial loss on the whole batch, or create an expensive shipping buffer which also incurred unsustainable losses. So at one point the company ditched a "mostly high-quality" supplier for a consistently terrible one. Being able to tune the production line and let it run at a predictable rate was immensely more profitable than getting fewer average component rejections.
And I believe this approach also works in large organizations. You don't want to have two sets of baselines for a big project depending on "how long will it take to get working environments"; you want always the same kind of environments and use that as a reliable figure in your planning. Both ISO 9000 and ITIL include continuous improvement mechanisms, but they're not higher priority than having a predictable, consistent delivery.
lucm, indeed.
Who have 20+ years experience in favor of outsourced "engineers" for 1/3 the salary and 1/10 the experience.
/ not bitter
Companies usually define IT as a cost center because money goes into the pit and no money comes out. They prefer putting $100 into something and getting $200 out of it. Give the sales staff a huge expense account and huge sales commissions and the money just pours in. Give the IT staff entry-level pay and continuously cut their budget because all you ever see is money going down the drain quarter-after-quarter. At some point they determine they really don't need IT and they save even more money. #Fail
Best Practices are appropriate in the obvious (simple) domain. https://en.wikipedia.org/wiki/Cynefin_framework
Oracle, SAP, IBM and other expensive licensing deals.
You can't handle the truth.
Active Directory is good, until it's landed with too many insane Group Policy Objects. Seriously, it'll make some people's lives just a living hell, especially developers. It's astounding what will fail to install when you can't check for updates. But, then again, you can put them and their machine in a different group with a different set of policies, but I haven't been to a shop yet that realizes that's totally a thing.
And yea, let your developers have the latest OS and updates. Make them the canaries in the coal mine. They'll appreciate the freedom and understand when it goes bad.
If your organization isn't organized enough to use a directory service... that's your first problem.
Agreed. The disorganization isn't an IT problem - it's a management problem.
"logon.bat". Ha. Welcome to 1995.
That silly logon.bat does exactly what it is supposed to do, no more and no less. Just recently, my company welcomed the 20th century. Not an all that uncommon situation for SMBs. On the other hand, many large businesses are still trying to deploy hardware/software from projects that are as old. NHS for instance.
New does not always equal better. The org I work for doesn't need/can't use anything beyond a .bat script. I don't think most orgs (functionally) really need more. Using another method to accomplish the same goal is change for the sake of change but it isn't improvement. Changing to group policy and powershell is nice technically but does that change actually make a difference to anyone?
Never said automation required AD. All I said is that AD can be leveraged to allow automation... if AD is setup to allow some rules that the automation can follow. If the rules are so complex that stuff doesn't work, then you are spending all your time dealing with tweaking rules or with manual fixes. Automate what you know are actual rules and then handle the exceptions. That's the reason for the simple logon.bat script - that's about all that can be automated to a simple logon.bat is all that's needed to do the job.
If management doesn't like the cost, management can start enforcing rules that can lead to cost saving automation or management can accept and pay for the cost of having all the exceptions.
Boss: "Let's deploy this application to the cloud!"
Sysadmin: "Does it make sense to put it in the cloud?"
Boss: >Holds up a CIO magazine with a picture of a cloud on it< "Because it'll be in the CLOUD"
Sysadmin: "What's this application going to do? What type of data is it going to be handling?
Boss: "But it'll be in the cloud, it'll be <looks quickly in magazine> a fully virtualized extensible angular flask framework!"
Sysadmin: "You're just reading buzzwords!"
Boss: "Let's senergize our git repos with our FOSS machines!"
Sysadmin: "Fuck me."
Yes Francis, the world has gone crazy.
IT Best Practice: Avoid asking Slashdot for advice on what 'best practices' IT should avoid at all costs at all costs.
12 'best practices' IT should avoid at all costs
3. Tell dumb-user stories
Is this really a best practice somewhere?
See above.
The article is nice on pointing out problems but has zero answers. I recommend Activator, it outlines the same problems and gives solutions. http://amzn.to/2qHTDaM.
tora
1) Don't hire creimer.
Why not? I have a 98.8% SLA rate.
2) Make sure if he's employed at the competition, that he STAYS there!
That could explained why the Russians wanted me to work stateside.
I miss back in the day when the trolls were actually creative and would write fiction about the sex lives of Slashdot editors rather than harassing ordinary users.
We had some great literary talent back in the day.
Steals Lunches from Associates?
A company I quit in generalized disgust a couple months back used all dozen... yes... *all* of them as their "Foundational IT Governance Principles." Anyone want to mail them a prize? (Feel free to parcel it out in hydrocarbon soaked brown paper bag for, let us say, a warm delivery to their doorsteps.)
Both of you are wrong. The network name is not relevant to the user. There are a few things when selecting a printer
Network Name
Name
Description
Location
If you fill these in properly you wont have any users bothering you. Also if your group policy is setup correctly you can push out the right printers to the right people.
That's best practise and it works.
It really is that simple.
1. Measure ticket solved count and time. Fire people who don't meet the quota. We lost good guys that helped without tickets.
2. Lie to upper management about automation level. Fire almost all people because they are no longer needed. Result is that everything takes very long and everyone is always too busy. But cost savings for IT is huge.
3. Put production and test database on same machine.
4. Make backup use same disk server as default server so when disk server faults...
CONSULTANTS!
What are you doing with your print server that you have to "manage it?"
An office with 3 users isn't going to create OUs at all. They will just use the default containers instead along with the default group policy which again requires no user intervention to maintain.
Most organizations are not better off without a directory service. Sure they exist, but they are definitely more the exception to the rule.
Hell no, developers are the worst at this. Most developers I know can tell you how to allocate memory but have no idea about group policy let alone general administration tasks. They'll make every service account use an admin account to get around security practices and creating proper service accounts which would be secured in a different OU.
GPOs are like VLANs, a lot of people discover them and then go nuts, then they usually simplify and then its all good again. If things get too out of control create a new OU, break inheritance and start fresh, its not hard unless you have no business administering Windows networks.
GPOs? Let's not go nuts! Signed My employer
"UNIX is very simple, it just needs a genius to understand its simplicity." -Dennis Ritchie
You are spot on, OP must be running less than a dozen machines if he thinks skipping a DS is intelligent in the least. Some of the worst advice I've seen on here, thanks for being a beacon of light.
Ok, I work in an organisation with two AD domains, n physically separate networks (where 2 n 4, I don't think it's currently greater than 4 but I could be wrong), and I have accounts on both AD domains.
Domain1: Covers several hundred machines on several sites, so I suppose it makes sense (though the way my organisation is fragmented, with so many little fiefdoms, sometimes you wonder), in my case, the only use I have for that domain logon is for email, and even then, this isn't necessary as part of our email is 'outsourced' and I usually pick up my mail via IMAP on my phone from that, irrespective of whoever's fiefdom I happen to be in...
So, what use is this domain?
user management? - see comment about fiefdoms, people leave, IT never get told, these is no official mechanism in place for notification and removal of user accounts, IT have tried for years to get one in place...
resource management? - see comment about fiefdoms, it got to the point there was so much bickering they ended up having a system where everything was shared RW to any domain user...thanks to a manglement order (yes, würm central folks, AV can only do so much..).
Backups?, certainly, yes they're carried out of the servers, but yes, people still keep most of their work on their local Desktops, and no, they don't necessarily get backed up...
Still, they do use the shared calendar, they think that's a 'killer' feature..wow, an IT equivalent of Douglas Adams's digital watches...
Domain2: Is indeed your classic 'less than a dozen machines', the majority of which are special function (i.e. control equipment), the majority of which are single-user, and, on a very regular basis, that single user is me, logged into 4-5 of the machines. This domain currently has 4 users, historical max number? 6.
Having a full blown AD server setup 'managing' this is pathetic overkill, and it was insisted upon by manglement despite ourselves and IT saying it was a waste of time and, more importantly (as it came out of our budget), money.
This is the point, there's a magic number of machines/users where it might make sense to run with AD, below that, forget it, it's all cost for no benefit.
There's also a type of organisation where, despite numbers of employees in the hundreds, despite hundreds of machines and multiple sites, implementing AD is as productive as pissing in the wind..
As it's all SEFP, I just sit back and munch the popcorn...
Ah, the ol' protoduction trick.
No technology will help if you have shit processes and petty politics. Don't blame the tech, blame the shitheads.
The last large company I was in (a major bank) was indeed doing, I think, all of the recommended 12 practices - oh, hang on, you mean those are things we should not do? Damn!
Those daily SCRUM meetings, including half a dozen people on speakerphone from what sounded like a busy market square in downtown Mumbai somewhere (complete with cow noises) - yup, they went really well.
"Cats like plain crisps"
AD is quite possibly the only thing m$ft ever made which isn't a total piece of crap. It's the only thing which makes babysitting a hundred of their f***** up machines tolerable. Now if only flash would deploy properly out of the box.
Continuous integration is just code words for "I/we can't be trusted to deploy software in a disciplined or even competent fashion."
No joke. It's a surefire way to grind your IT department to a halt and the rest of the company along with it.
Number one on that list should be "Make people remember ridiculously long passwords, force them to change them every other day and make sure that they have to invent new passwords every time, with no semblance to any of the past 1000". Not only will you ensure that your help desk is drowning in "I forgot my password" calls, especially after days like Thanksgiving when there's a 4 day weekend, it will keep people busy coming up with new passwords.
Number two is of course "and don't write it down". So you can make sure that people not only get creative in how they note down those 12+ character word salad you dished out to them, you can also make sure that they don't dare to talk to you anymore lest you learn where they wrote it down.
I think you can easily take it from here. Make sure you don't forget to keep the storage team busy with ridiculous "Best Practice" backup requirements that are impossible to fulfill and you should be the best CISO ever. Well, at least on paper. And we all know you only make big leaps in your payment when you switch jobs, something you'll do often if you heed the IT Security Best Practice recommendations.
Because you'll leave sunken companies behind you.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Another good reason to avoid System D on linux then.
You're juat excited by AD because it worms whereas most Microaoft products dont technically work.
Flash is a horrible flaming turd of an application/platform that is depreciated and can't die in the fiery pits of hell as fast enough. They could never figure out what it wanted to do so they they tried to have it do everything and to sell it, they gave PHBs everything they asked for that could technically be rammed into code (notice, I didn't say "work"); thus causing today's problems. Please try to help along its demise as expediently as possible by getting it out of your organization.
[I know, tell you how I really feel.]
"Be particularly skeptical when presented with evidence confirming what you already believe." -
Lots of different types of servers needing individual TLC is stupidly expensive in the long run...
Open plan offices and cubicle seas.... That's all from me.
Actually, the grandparent has a point. I used to be a big AD/LDAP advocate but these days I recommend avoiding it. There are too many ways it can fail on client devices and debugging its problems is pure hell.
And In return you basically get only password synchronization. Even group membership management is not important anymore unless you are still using Samba. And AD doesn't automate a lot of important tasks like setting up wireless connectivity, installing updates and so on.
Yup, had, cuz it ain't YOU, heavy Chris!
Anything more than the absolute minimum involvement by HR in hiring.
Passionately Indifferent
Dude, you deserve a prize; I've been a Slashdotter since the 90s and these useless troll-posts of yours have been attached to every news story on here without fail since then.
For nearly 20 years, trolling uselessly, without any content or point.
It's pretty impressive
I don't know the meaning of the word 'don't' - J
My last IT employer had a vast set of milestones they wanted to hit by 2012. Goals! ha
One of them was to make the company be just like Zynga. Mind, Zynga was already in failure mode long before this visionary goal was born, and the work we did had absolutely nothing to do with anything Zynga did. .Very different products and markets.
Apparently the people who did the goals only looked at revenue or some sort of number where Zynga looked great on paper. But some of us knew the truth and openly laughed at that goal. This didn't please management. Oh well. Don't make "be like a company going down the shitter" as a goal and maybe your employees won't laugh.
Sig for hire.
"Engineering" and "Operations" need to be in the same team. Otherwise your ops turn into monkeys who only know how to run scripts. When the sht hits the fan your ops should know the systems top to bottom, install to archive, configuration to binaries. Seperate ops from enginerring for infrastructure or systems including database adminstration at your peril.
Not true. A lot of application use (or can use) AD/LDAP group membership to handle rights management. I am currently setting up a storage appliance that uses group membership to determine if an AD user can log in and what rights he gets.
In defence of the cloud, here's how I usually see the conversation go:
Boss: "Let's deploy this application to a server in our data center" ... ...
Developer: "OK"
Developer: "We need a server in our data center. How can I get one?"
Sysadmin: "You'll need to engage an architect to produce an infrastructure design, then bring it to our vendors to get a quote, and then talk to the accountants to get your project funded. Make sure you get sign-off from these 8 different managers, and we can install your server. Then you'll need to talk to the networking guys about connectivity. We can have everything ready for you in about 6 months."
Developer: "Uhh...OK. Let me talk to some people and get back to you..."
Boss: "So when will our servers be ready?"
Developer: "I've just signed up for an AWS account and I'll go and spin up some EC2 instances. They should be up in about 5 minutes. If I put it on the corporate card, can you approve the expense?"
Boss: "Yeah sure."
The reality is, in a lot of big companies, the services that IT provides are really shitty and you might be able to get a lot more done if you work around them.
There is zero reason to run Windows. Anywhere.
You would know, creimer. Him and you fuck them together.
Don't buy anything in Gartner's 'magic quadrant' - don't even allow the vendor to give it to you for an extended free trial. The magic quadrant should be considered "death-knell of any organisation that uses it".
While you're at it, don't do the 'best practice' of buying your most expensive software products on the golf course either.
> AD doesn't automate a lot of important tasks like setting up wireless connectivity, installing updates and so on.
Checking my machine here, I have a GPO that creates my Corp wireless profile and sets it to auto-connect using the certificate that is auto-enrolled on my machine.
I have another GPO that points me to a corporate update server for Windows updates, but still conveniently leaves the option to check for updates directly from the mother ship.
An IT person had to create those GPOs, is that what you mean by not doing it automatically?
> A lot of application use (or can use) AD/LDAP group membership to handle rights management. ... and with ADFS or another federation service those apps don't have to be on premise either. My current customer uses Ping for federation, and they have dozens of cloud apps that do automagic single-sign-on.
(I work for Microsoft, but the above is not paid shilling. Yes, I know that by working for MS my opinion is immediately invalid.)
"logon.bat". Ha. Welcome to 1995.
I have logon.bat on my Windows PCs to map drives to my FreeNAS file server in my home office.
Domain 1 has eighth layer political problems that no technical solution can address.
Domain 2 doesn't sound like it is a great application for a domain at all. If it were desktop users on the dozen machines and not industrial control equipment you could make some argument for Azure AD, but you'd have to show me there was some value in it before I'd implement.
Uhhhh, you can map network drives that reconnect at logon...
Most of this is just silly tripe.
If you have an Enterprise Agreement (EA) with Microsoft, they immediately begin to pressure you to start using their "free stuff":
Anti-virus, hyper-visor, cloud storage, and so much more. You didn't buy these items specifically, but THEY'RE FREE! Every other year I have to fight a fellow Systems Engineer who wants to move to Hyper-V from VMware because IT'S FREE!. We've already moved to Microsoft's crappy anti-virus software, because IT WAS FREE!.
Stop, just don't do it... it's NEVER FREE!
Jeez no shit. The guy's a moron.
Seriously, if people leave and you're not told... then implement a policy whereby if an account isn't logged into for two weeks (for example) it gets disabled. Not deleted; disabled. Then create a one-line Powershell script that scans through the directory nightly and disables all accounts that haven't logged in for two weeks (except service accounts... make sure your directory is properly set up for this!). If you wanna get real fancy then have it email the manager defined in AD that the account has been disabled, then the onus is upon them to call you or your helpdesk in order to get it reenabled.
Worst case? The user gets back from their three week trip to Europe and can't login so calls Helpdesk. Big deal... 5 minute call. It's written in the policy and is not overly draconian.
N/T
Twitter supports and protects racists - by smearing their critics with the "Hate Speech" label.
3. Tell dumb-user stories
You know them. The classics have punchlines like “Whiteout on the screen,” “Let me get this straight -- you’re having a power outage and you can’t understand why your PC won’t boot,” and “I told him to try reversing the plug on his printer ... and it was a three-prong plug (snicker)!”
On what planet is any of that a "best practice"?
I see this over and over. A company needs high reliability at some site so they buy one connection from Company A and another connection from Company B.
Then the customer has an outage in which both connections go down within milliseconds of each other. "WTF" they say, "this is why we bought one from AT&T and one from Zayo"!
75% of the time Company B will just buy the last mile from Company A!!! Even in the remaining 25% of the time they are almost certainly sharing some network infrastructure. Maybe Company B is colocated in Company As central office. Maybe Company A is using long-haul fiber from Company B to get back to their core network.
If you really need diverse redundant connections buy both of them from the SAME company and specify in the service order that they must be on physically diverse paths with no single point of failure. It will be expensive.
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
If 1/3 the salary and 1/10 the experience gets the end goal accomplished in an acceptable (if not ideal) manner to move or sustain the business, then that's the right choice.
My suggestion is more old people need to get together to consult and be the parties that are outsourced to, if, indeed they can do it more competitively.
I left tech completely. Great hobby. Shitty career.
Uhhhh, you can map network drives that reconnect at logon...
The logon.bat drops all existing mapped drives before mapping them again. If Windows decides to "forget" that a mapped network drive exists, I just click on the shortcut to the logon.bat file to refresh the mappings. A bat file can be copied to multiple PCs and VMs to have the same mappings.
Chris, this is Bill in accounting, can you get back to work please? And please use the Glade next time you're in the bathroom?
3 passwords tries = a lockout is the STUPIDEST "security" scheme ever. At an old job, a disgrunteled person used a script to login to the CICS region with the admin usernames very quickly. They locked out all admins in less than one min. Someone had to physically travel to the data center in another state and use some sort of local console to get in.
You don't manage a collective of machines do you?
LDAP is rather solid and has been around for a digital eternity. Its not difficult to implement, can be configured to adhere to most any security standard, and can be learned with a few days of training for any competent administrator.
Fully licensed blockchain psychiatrist
Fuck that.. where equals? I keep 3, what's said in IT STAYS in it
If you don't believe in having technical managers or having expert programmers in staff and somehow believe you can buy expertise your model is going to be shit no matter what you do. Stay the fuck away from ITIL, and if you're already ITIL, plan/build/run will not save you. Also service now is not a good solution for ticketing either.
http://edition.cnn.com/2017/06...
More public sector incompetence. Private sector accommodation would never be so lethal as the risk of a lawsuit acts as a deterrent and spurs better performance. That's the discipline of the free market.
--
roman_mir
Not having internal SLAs means you are wise to avoid internal services. You either buy outside, or roll your own. Such smokestack applications are quite duplicative & costly, but it beats getting screwed because some other department decides that your project doesn't get what was promised.
I'd put as number 1 on my list not to follow anything called a "Best Practice"...unless you know WHY it's a best practice and that the conditions under which it's actually the best thing to do correctly describe your company/environment.
So every computer and server in the company should have separate accounts and passwords?
What if you synchronize them from an Identity provider using a different technology?
THEY are the problem here!
Following those policies make you INSECURE.
Does it work on Macs?
NEVER allow developers to develop their prototypes in production environment! we have some software managers who insist this was a good idea and went all the way to the CEO to get this through despite numerous protests from the other team. in the end, he got what he wished for, now we are waiting for the mission critical production systems to fall apart.
If you are using MDM in Azure, yes.
"Corporate Networks" are a concept that needs to just curl up and die. I'm not talking about the physical network, but the logical layer where people get the idea that a high fence will protect them and they can be as sloppy as they want inside of it. Sorry, but it's time to throw away the safety blanket and get with the fricking cloud at the app-level.
Humble brag fail. 98.8% means your shit is unexpectedly down four days a year. That is fucking awful. No wonder you have so much time to pollute Slashdot.
98.8% means your shit is unexpectedly down four days a year.
Nope. Out of every 100 tickets assigned to me, 1.1 tickets won't close on time because I'm waiting for a response from another department. Only the telecom guys have a 99.9% rating.
So you are using a different definition of SLA. Do you know what a SLA is?
So you are using a different definition of SLA. Do you know what a SLA is?
The Service Level Agreement for enterprise help desk tickets is closing tickets within a specified timeframe: urgent in four hours, high in two days, medium in four days and low in seven days. My SLA rate at 98.8% typically puts me in the top three of the department. The reason I don't have a 99.9% SLA rate is because some asshat on the server team is too busy to respond to tickets in a timely fashion.
An SLA is negotiated - there is no "standard" service level agreement. "YOUR DEPARTMENT's service level agreement is," not "THE service level agreement is."
The reason you don't have a 99.9% SLA rate is because you have not bothered to develop the relationships necessary to ensure that someone on the server team wants to help you meet your SLA, and will respond in a timely fashion.
I'm sure your characterization of the team as populated by "asshats" has nothing to do with the fact that they don't pay attention to your demands for service, though.
An SLA is negotiated - there is no "standard" service level agreement. "YOUR DEPARTMENT's service level agreement is," not "THE service level agreement is."
Call up your help desk and ask what their response times are for urgent, high, medium and low tickets. It won't vary that much from what I wrote, as response times are pretty much standard.
The reason you don't have a 99.9% SLA rate is because you have not bothered to develop the relationships necessary to ensure that someone on the server team wants to help you meet your SLA, and will respond in a timely fashion.
Correct. Because in an enterprise environment with thousands of users, I'm just an interchange cog. Here today, gone tomorrow.
I'm sure your characterization of the team as populated by "asshats" has nothing to do with the fact that they don't pay attention to your demands for service, though.
On my current job, an asshat on the server team ran the printer mitigration script and went on vacation. I spent a month cleaning up the mess. It didn't help that the server team decommissioned the old print servers a month ahead of schedule without telling anyone, generating 100+ help desk tickets from users who had to go without printers for three days. When the new print servers came online, those tickets went away.
And, then, five years later, an audit finds that there is data on AWS that needs to be better secured, and the company gets heavily fined with an unrealistic deadline for conforming to the (possibly unclear) rules.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Critical: "Initial response within 5 minutes."
High: "Initial response within 2 hours."
Medium: "Initial response within 24 hours."
Low: "Initial response within 72 hours."
And for all of these, "Initial response" means engineer has acknowledged that they are investigating the incident in the ticketing system. Looks like I was right.
?? What does this have to do with your interactions with the server team? There's not thousands of people on that team. And once you get a contact, you cultivate that contact. You keep saying "interchangeable cog," but you're also fond of reminding us that you're on a 5-year contract. If you're on a 5-year contract, and you're not making the attempt to build working relationships with the people you have to work with, then you're the stupid asshat, and I'm guessing that the only reason you have your pretty low 98% SLA delivery rate is because you behave like a complete douchebag and escalate constantly to management.
And what does that have to do with your autistic inability to forge relationships with people?
Looks like I was right.
About time you got to the only point that matters to you.
What can I say, creamy-boy? I'm often right. Don't be upset. And think about how your autism impacts your ability to forge connections with your co-workers. Devoting some time & effort to building those connections will mean that your SLA adherence will get higher.
And think about how your autism impacts your ability to forge connections with your co-workers.
Too bad I don't have a disability.
Devoting some time & effort to building those connections will mean that your SLA adherence will get higher.
I haven't worked in help desk in nearly ten years. The SLA metric isn't required for my current job. BTW, I'm still in the top three of my department. That's probably why I got an extra month of pay as a Christmas bonus last year.
"Too bad I don't have a disability."
I'd disagree. ADHD for sure (why do you skip skip skip words?). OCD (why do you keep coming back to reply?). Asperger's (self-evident). Obesity (self-evident). Delusions (You're gonna make millions from your ebooks?)
But you know what? I'm no better. But I admit it.
I'm pretty sure you do!
Then why tout your high levels of compliance? If it's irrelevant, why did you care enough to bring it up?
You work for the government. Low standards and laziness are pretty standard in bureaucratic positions like yours. I'm not surprised that you could manage to be second loser with such a low SLA compliance rate.
Again, low standards - if you worked hard, and delivered good results, you could have a bonus program that gives you what amounts to an extra month of pay or more every quarter. I mean, for you, it would only amount to a few extra bucks, but you're pretty poor, so it would probably help.
"Open plan" work areas, where there isn't even a short cubicle wall between you and the conversations and standup meetings of your co-workers. Headphones, white-noise generators, and noise-cancelling can only do so much. And they have their own problems.
The motion of people in your peripheral vision -- or right in front of your goddam face -- is distracting, too.
This is a fad that has not gone away, despite the obvious problems.
There's no time like the present. Well, the past used to be.