Your Role Is Changing
-
I've never "implemented" and never will "implement" DevOps because, as the article said, it's a culture. It didn't have a name back in 1980 when I got my first adult civilian job but it's always been the way I've done things. The really sad part about this is that some people actually do think this is a new concept. DevOps is a nice short name for it. We used to call it "team work" and "working together for the same company".
Also and contrary to popular belief, there IS an "I" in team. Along with the incredible team work that we all enjoy where I work, individual contributors are encouraged in the areas of experimentation and innovation. That's not to be confused with the "cowboy" syndrome, which none of us tolerate.
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) -
Nice art work, Jeff. For once, someone used a font that was large enough for me to read it.
But you are off subject. We are talking about 2 different things. The concept of DevOps sprang out of the Agile and Lean movements. I'll let you read about it here:
http://theagileadmin.com/what-is-devops/
Teamwork is what works in all well implemented work environments. It has nothing to do with DevOps.
-
Gail Wanabee (4/23/2015)
Teamwork is what works in all well implemented work environments. It has nothing to do with DevOps.Heh... that's precisely what I'm talking about. Most people make the mistake of thinking they're different. And while people may think it "sprang out of Agile", only the buzz-word sprang from there. People who have been doing it right have been doing it right for decades before Agile became a "thing". Interestingly enough, Agile was also a great practice long before it was called Agile. None of this stuff is new or better. It's the way things have always been done by people dedicated to getting stuff done.
The article you provided is, however, spot on. Especially the following paragraph...
For this purpose, “DevOps” doesn’t differentiate between different sysadmin sub-disciplines – “Ops” is a blanket term for systems engineers, system administrators, operations staff, release engineers, DBAs, network engineers, security professionals, and various other subdisciplines and job titles. “Dev” is used as shorthand for developers in particular, but really in practice it is even wider and means “all the people involved in developing the product,” which can include Product, QA, and other kinds of disciplines.
It's a pretty good description of how I've been doing things even while I was in the service in the '70's and ever since. And, like I said, we used to just call it "Team Work". 😉
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) -
I still find it funny there is such a huge wall in most companies where you have to remind people to collaborate with one another to get better results. It should be a given period.
I've always been the guy in between Dev, Ops, QA and even Customer Support. I know without a doubt how no collaboration between all of these teams can cause such a headache, especially when it comes to the lone DBA working with an army of developers who think they can all do their jobs without the help of the DBA period.
You know what happens when you don't work together, especially when your application is heavily utilizing the database to read and write data to provide a service to the end user? Serious performance issues that lead to serious customer experience issues that lead to serious money loss that lead to serious job loss.
Easier said than done for sure. But, DBA or not, everyone should make an honest effort to collaborate without the need for a DevOps movement. Ops should be talking to Devs, Devs should be talking to Ops, QA should be working side-by-side with Devs and honest efforts across all teams should be making strides to increase awareness around each other.
But, I can only dream I guess. 😛
-
I've always approached DBA tasks with the heart of a developer who loves automation. Granted, I don't look at data like that, but that's a different conversation. 😉
When it became obvious that a database needed to be tuned, I didn't click my way around SSMS, figuring out what needed to be reorganized or rebuilt, I dug into the system tables and developed an automated process for doing it. When a text file had to be loaded and populated every day, I didn't even consider loading it manually every day. I wrote a procedure to automate it. It's like that with everything. Unless we automate things, we're stuck doing them manually and end up having no time to do anything else.
This is certainly nothing new. Even when I was doing development only and had no DBA responsibilities whatsoever, I tried to automate everything. Writing manual processes and manual steps just builds a fiefdom from which you can never escape. You'll be bogged down in manual stuff forever and never have the opportunity to grow.
On a separate note, nice artwork, Jeff. My compliments on finding the "i" in team. 😀
-
I wonder whether any companies use the DevOps idea to draw developers into a support role and then shut the gates behind them?
It might be that many large established companies have little need for in-house developers but struggle to find support staff?
-
stevenp333 (4/27/2015)
I wonder whether any companies use the DevOps idea to draw developers into a support role and then shut the gates behind them?It might be that many large established companies have little need for in-house developers but struggle to find support staff?
We IT folks, especially developers, are like cats. If our fur doesn't get stroked the right way, then we will wander off a new opportunity. Corporate can try to fence us in the backyard, but we'll find a way out.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
-
stevenp333 (4/27/2015)
I wonder whether any companies use the DevOps idea to draw developers into a support role and then shut the gates behind them?It might be that many large established companies have little need for in-house developers but struggle to find support staff?
Define shut the gates behind them?
Plenty of companies are starting to hire DevOp specific roles. They are looking at them as an elite group that tackles a set of predefine focuses like bridging the gap between worlds. Both developers and network/system admins who have a passion for both worlds are joining the forces. So, I have no doubt that when work is lacking in one area, they may have the opportunity to move into another. That other may be DevOps if your company actually moves towards the direction of hiring specific people versus just promoting the overall culture.
One good example is Site Reliability Engineers. They are mostly identified as part of the DevOps team or with the similar focuses. A good friend of mine who is primarily a Python developer transitioned into such a role for LinkedIn. It's opened up a wide range of opportunities for him where he is still doing development work. He just tackles a different set of focuses with his development efforts than just making generic apps all day.
-
By "shut the gates behind them" I just meant their work load might become predominately support related from then on.
My feeling is that companies might find it hard to recruit suitably skilled people for some support roles. Describing a role as "DevOps" might tempt people to apply who would otherwise shy away from support.
I'm sure DevOps roles can be very rewarding. I like the idea.
But I also know some support roles are not for everyone.
-
Eric M Russell (4/23/2015)
...They can now login using their vanity 'SA' account and feel important......and then read your post and feel patronised??? That's not collaboration!!!
(I am assuming that Mr Russell is exercising his right to place his tongue in his cheek.)
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
-
Gary Varga (4/27/2015)
Eric M Russell (4/23/2015)
...They can now login using their vanity 'SA' account and feel important......and then read your post and feel patronised??? That's not collaboration!!!
(I am assuming that Mr Russell is exercising his right to place his tongue in his cheek.)
There are scenarios where applications or "power users" login to the server under the 'SA' account. Any number of arguments are put forth that this is necessary, such as that it would require too much effort to change the code or that the user occasionally needs to run queries or view execution plans against any table.
In other words, they actually don't need SYSADMIN privilliage. In that case, it's totally appropriate for the DBA to grant them access to and account called 'SA' but with decremented permissions.
Unless the user explicitly states that they need permission to create, drop, read, or write any object without going through the DBA, and executive management signs off on such a request, then a request from business for logging in under 'SA' account can be interpreted by the DBA however he chooses.
This is collaboration; it's giving the users what they need when they need it.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
-
Gary Varga (4/27/2015)
Eric M Russell (4/23/2015)
...They can now login using their vanity 'SA' account and feel important......and then read your post and feel patronised??? That's not collaboration!!!
(I am assuming that Mr Russell is exercising his right to place his tongue in his cheek.)
OK, I'm sorry for the remark about some users wanting access to the 'SA' account just to feel important. I must have been in a flippant mode, and I shouldn't have stated it that way. I acknowledge there are plenty of legitimate technical reasons why some applications need to login as 'SA' or at least with elevated permissions.
However, whether they are actually granted full sysadmin permissions upon logging in as 'SA' is another issue entirely. It's normal for the DBA to throttle permissions up or down as required, and unfortunately 'SA' is just another shared user account in some organizations.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
-
Eric M Russell (4/27/2015)
Gary Varga (4/27/2015)
Eric M Russell (4/23/2015)
...They can now login using their vanity 'SA' account and feel important......and then read your post and feel patronised??? That's not collaboration!!!
(I am assuming that Mr Russell is exercising his right to place his tongue in his cheek.)
OK, I'm sorry for the remark about some users wanting access to the 'SA' account just to feel important. I must have been in a flippant mode, and I shouldn't have stated it that way. I acknowledge there are plenty of legitimate technical reasons why some applications need to login as 'SA' or at least with elevated permissions.
However, whether they are actually granted full sysadmin permissions upon logging in as 'SA' is another issue entirely. It's normal for the DBA to throttle permissions up or down as required, and unfortunately 'SA' is just another shared user account in some organizations.
You are not wrong about refusing the access. They'll not learn anything unless you help them and demonstrate that they are wrong to ask for it. That would be collaboration 😀
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
-
Eric M Russell (4/27/2015)
OK, I'm sorry for the remark about some users wanting access to the 'SA' account just to feel important.I wouldn't be. I'm glad that someone has the hair to say such a thing. I've had a lot of people give me the "because I'm a manager" or "because I'm important" reasoning and just won't do it if for no other reason other than to protect THEM for their own silly request. I even had one GM tell me that he'd fire me if I didn't give him the privs. My reply was "Thanks boss... I could use the vacation". I followed that up with the "Look... you hired me to protect the data. What you don't know is that I'm also devoted to protecting you. Tell me what you want to get done and I'll make it happen but it's in my job description to "effectively manage security" and that's what I'm doing now."
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) -
Jeff Moden (4/28/2015)
Eric M Russell (4/27/2015)
OK, I'm sorry for the remark about some users wanting access to the 'SA' account just to feel important.I wouldn't be. I'm glad that someone has the hair to say such a thing. I've had a lot of people give me the "because I'm a manager" or "because I'm important" reasoning and just won't do it if for no other reason other than to protect THEM for their own silly request. I even had one GM tell me that he'd fire me if I didn't give him the privs. My reply was "Thanks boss... I could use the vacation". I followed that up with the "Look... you hired me to protect the data. What you don't know is that I'm also devoted to protecting you. Tell me what you want to get done and I'll make it happen but it's in my job description to "effectively manage security" and that's what I'm doing now."
From what I've seen it typically works like this, the development team states that "Process XYZ needs to login as 'SA' or else it won't work.".
They don't know exactly why XYZ needs elevated privillages; they just know that it has always used 'SA'. At this point the DBA can setup a trace to determine what XYZ really needs, and then either provide the team with a new dedicated account, or if there is a political or technical snag that demands 'SA' continue to be misused, then the DBA can decrement the 'SA' account's privillages to minimal required and just let them continue using it that way.
What's important to understand is that any given account for which the development team has credentials will be misused by the team (at least) on an occasional basis, if not habitually. They'll use it for troubleshooting production issues, ad-hoc reports, or even to make black-ops deployments on a Friday afternoon, so always insure it has minimal permissions based on it's originally intended purpose.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 15 posts - 16 through 30 (of 31 total)
You must be logged in to reply to this topic. Login to reply