This blog post covers how I tracked down when SMB 2.1 support was re-enabled in ONTAP 8.1.x 7-mode, having been disabled in the initial release of 8.1.2.
This guide is written for fixing a corrupt or broken RLM firmware. It is applicable to both 4.x and 3.x versions of the RLM firmware. Although this may help with other corrupt or broken RLM issues, the most common error this fixes is
[rlm.firmware.update.failed:warning]: RLM firmware update failed, Error Flashing linux.
Last week, via a tweet from Frank Denneman, I discovered a whitepaper that covers the differences between storage IOPS and storage throughput, as well as best practises for performance benchmarking.
As someone relatively new to the inner workings of storage, I found it very enlightening. Particularly the fact that there’s a clear difference between IOPS and throughput, and you need to decide what you want from a storage system before you benchmark it. Well worth a read, even if it’s the first 9 pages which covers the different types of workload (IOPS vs Storage).
The whitepaper from EMC is here: Elements Of Performance And Testing Best Practices Defined
Frank’s post, with a summary of the white paper is here: Awesome read: Storage Performance And Testing Best Practices
Share and enjoy 🙂
This post covers how to check the current firmware version of your disk shelves in a NetApp FAS storage system
As part of a series of posts on moving IT from Reactive to Proactive, I share my thoughts on how to ensure that IT is meeting your company’s needs through regular meetings with group managers.
How do you know if IT is meeting your company’s needs?
The short answer is, unless you are talking to your non-IT colleagues and managers regularly, you probably have no idea.
Why do I say this?
- For many departments, IT is so invisible that it doesn’t even cross their mind when a new project is kicked off.
- Often non-IT staff feel that their problems either can’t be, or won’t be solved by the IT department.
- Sometimes there’s also a feeling that the problem is “only a niggle” and that they don’t want to tie up IT with it.
You need to get your colleagues out of this mindset, and get IT involved into the fabric of the company.
It is your job to make sure that IT is meeting your company’s needs. IT is an asset to your company, make sure your colleagues know it. Go out there, mingle and build rapport. I cannot stress this enough. The benefits are often intangible, but in my experience are absolutely essential to making sure IT don’t get blindsided by urgent IT issues in non-IT projects.
If you’re not making sure that IT meets your company’s needs, your non-IT colleagues may start to explore IT’s version of hell: “Shadow IT services“.
So how do you stop this? How do you make sure you’re meeting your company’s needs?
My advice, no matter how big or small your company is, is to meet regularly with the department leads/managers and discuss:
- Ongoing IT issues and progress (client to IT)
- New projects/initiatives/issues (client to IT)
- Updates from IT (IT to client)
The idea here is to create a flow of information in both directions. Build a relationship. Build a rapport.
Reaping the benefits
A lot of the benefits of meeting regularly as intangible, but very worthwhile in my opinion.
- Ensures IT gain greater visibility of the company’s overall goals, as well as individual group goals.
- The more you know, the more you can help, and the more IT becomes an asset and seen as an enabler.
- Helps to keep IT visible, in the forefront of the group managers’ minds
- Rather than IT being invisible
- Provides a conduit for information and issues.
- Helps IT to catch and fix issues before they become a problem for your company.
In case you’re curious how you go about this, here’s how I tend to do it:
Finding whom to speak with
Generally, you need to be meeting with a decision maker and the head of the department or group. If your company is large, you may want to strategically pick a group leader rather than a department leader as the group leader is closer “to the ground” so to speak and may have a better idea of what IT issues their staff are seeing daily. Often a company will have a project or programme manager. Meet with them too. Project-wise, no one knows more about what’s going on than a project manager.
Don’t kill yourself with meetings, though. If you have identified a lot of group managers, either pick the groups that you feel you’ll have the most impact on, or divide up the meetings with other IT colleagues.
Book your initial meeting 2 weeks in advance. As part of the booking, ask the manager you’re meeting with to speak with their colleagues/reports to gather feedback on IT. 2 weeks gives them enough time to gather that feedback. Book it for 1-hour, but let the manager know that future meetings will only be 30 minutes. (These are busy people, and they’ll appreciate the brevity of the meetings)
The initial meeting is mostly a lot of information gathering, so tends to take an hour. If you’ve never spoken before, you have a lot of catching up to do. You should:
- Ask what their department is responsible for
- Knowing what a group does, and their priorities, is important if you’re going to be supporting them
- Let them know why you’re having these meetings. Sell the benefits to them.
- Let the manager know that IT is here to help.
- You want to fix things.
- You want to help the company succeed.
After your first meeting, you’ll probably have a lot of action points or things to chase up. Don’t let this drag you down; it’s just a consequence of having not met very often. It won’t be like this every meeting 🙂
Regular meetings should be monthly, and roughly 30 minutes in length. Book the first one a month after your initial meeting. In the meeting you should provide feedback on any issues that were raised in your previous meeting, and see if anything new is upcoming. It’s also a good idea to check both sides are happy with the style, format and length of the meeting.
I tend to dub these meetings “<Department> Catch-up”, as that’s all you’re doing. If any projects or key issues spring up out of these meetings, you should be working on those issues outside of the catch up.
My regular meeting formats look like:
- IT progress update on previous issues
- Client update on current/new projects
- Any new issues?
Some notes on my experiences with this approach
I have used this approach at my previous company and my current company for the last 3 years. Over that time, I’ve learned a few things:
You’re being tested
Neither side is probably aware of this but, after the first meeting, you are being tested. If you walk out of that initial meeting with a list of stuff that’s wrong with IT from a group’s perspective, and you can’t come back with any plans, feedback, or answers to some of those issues, you’re going to have a hard time going forward. If you fail to act, the group managers will feed that back, and their colleagues and reports will see IT exactly the same as they did before: a blocker. You have a month to get answers or solutions; make that time count 🙂
IT is under-resourced in many companies. Don’t promise the world to the people you’re meeting with, but do let them know you’ll do everything you can given your resources. Generally, they’ll understand.
Use the catch-up to sell IT
If you work in IT, you know you do great stuff every day. Use the regular meetings to demonstrate to the group managers that IT are making a difference. Make your IT updates relevant to the group you’re meeting with. If you’re meeting with Finance, they probably don’t care that you’ve upgraded the Git servers for the Software team, but they probably do care that you’ve improved the performance of their accounts reporting tools.
Let me know what you think about this article. Does it make sense? Do you agree or disagree with my approach? Feedback is gratefully received, especially if it’s constructive! 🙂