|
IPv6 book is ace, but I stopped reading it and need a good reason to start again. This works
|
#
?
Apr 14, 2015 05:15
|
|
|
|
| # ? May 5, 2024 14:17 |
|
|
I have the Powershell book but only made it...5 chapters in? Thereabouts
|
|
#
?
Apr 14, 2015 06:43
|
|
|
I have the powershell book. I vote for powershell
|
|
#
?
Apr 15, 2015 13:28
|
|
|
I'm down to learn some powershell.
|
|
#
?
Apr 16, 2015 21:38
|
|
|
Powershell should be a lot easier reading than IPv6. How about we spend the next month doing powershell and then do IPv6
|
|
#
?
Apr 16, 2015 21:40
|
|
|
Good by me.
|
|
#
?
Apr 16, 2015 23:39
|
|
|
Anything that involves putting off ipv6 is good by me!
|
|
#
?
Apr 17, 2015 02:56
|
|
|
Sounds like it's Powershell! Powershell 3 in a month of lunches I have the book but have read more than a few pages but how fast do we want to go?
|
|
#
?
Apr 17, 2015 03:22
|
|
|
Sheep posted:Anything that involves putting off ipv6 is good by me! Storage was rough so this'll be a fun easy one. Maybe it'd be good to make separate threads to make it easier for people to jump in or for people to do multiple books?
|
|
#
?
Apr 17, 2015 03:49
|
|
|
Dr. Arbitrary posted:Storage was rough so this'll be a fun easy one. We could start a new one but with a Powershell title but I don't think we should split the enthusiasm.
|
|
#
?
Apr 17, 2015 03:52
|
|
|
Got my copy of Powershell in Lunches, it comes with a free eBook copy 
|
|
#
?
Apr 28, 2015 00:02
|
|
|
Does anyone have recommendation for more books along the following lines? The Phoenix Project The Soul of a New Machine I've managed to fall behind on the others, but I'm slowly working through EMC's Storage book.
|
|
#
?
Apr 29, 2015 23:25
|
|
|
the spyder posted:Does anyone have recommendation for more books along the following lines? For the EMC book, keep on struggling! It's tough.
|
|
#
?
Apr 29, 2015 23:32
|
|
|
Dr. Arbitrary posted:For the EMC book, keep on struggling! It's tough. I've been taking it one chapter at a time- and it's relevant now seeing as we have two Isilons.
|
|
#
?
Apr 30, 2015 02:23
|
|
|
I'm about 5 chapters into the Powershell book. I've read it on and off for a while now and like it quite a bit. One thing I havent seen mentioned yet in the book, but has been helpful for me is import-module whatever. Really adds to what can be done with powershell and shows you how baked in it is to Microsoft products now. I have AD imported as part of my profile now.
|
|
#
?
Apr 30, 2015 17:54
|
|
|
I'm at chapter 2 myself, but I think the reason we aren't seeing the import module, is because from 3.0. powershell automatically adds the module to the command you give? I know I have to use the import module on powershell v2. I may be very wrong on this.Only at chapter 2
|
|
#
?
Apr 30, 2015 18:54
|
|
|
Not exactly books but I've been resorting to helping people on the Ubiquiti network device forums when I can't sleep  To IPv6 books, that poo poo would keep me awake cause I love me some IPv6.
|
|
#
?
May 1, 2015 06:08
|
|
|
I gave up waiting for Jang's RHCSA7 and picked this up at lunch: Ghori's RHCSA & RHCE Red Hat Enterprise Linux 7: Training and Exam Preparation Guide Anyone want to enter into some sort of chapter completion-based blood pact let me know
|
|
#
?
May 18, 2015 17:57
|
|
|
Roargasm posted:I gave up waiting for Jang's RHCSA7 and picked this up at lunch: I think Jang's books have more quality but I'm not interested in waiting until November either. There's quite a few of us whom are interested in RHEL Certs and I'll try to advertise in other threads when I'm not on my phone later.
|
|
#
?
May 18, 2015 18:55
|
|
|
Roargasm posted:I gave up waiting for Jang's RHCSA7 and picked this up at lunch: I have the RHEL7 RHCSA Cert, I posted in the other thread, but figure I'll cross post. I passed in December, and I have the official course book right here. I don't think I can share any copies of it, but I'd be happy to give any guidance on what the labs and tests are like.
|
|
#
?
May 19, 2015 15:32
|
|
|
SIR FAT JONY IVES posted:I have the RHEL7 RHCSA Cert, I posted in the other thread, but figure I'll cross post. I passed in December, and I have the official course book right here. I don't think I can share any copies of it, but I'd be happy to give any guidance on what the labs and tests are like. Crosspostin' as well. I have the official RHCSA and RHCE books, but I'll pick this up and follow along
|
|
#
?
May 19, 2015 16:28
|
|
|
Are the official RH Course books not available to the public?
|
|
#
?
May 19, 2015 16:32
|
|
|
Tab8715 posted:Are the official RH Course books not available to the public? I'm pretty sure you get them by paying for official RH training
|
|
#
?
May 19, 2015 16:39
|
|
|
Well, I bought the book and it'll be here Thursday.
|
|
#
?
May 19, 2015 18:00
|
|
|
How does the scheduling work? I want to buy it today but I have a tendency to blow through a book so quickly it aint funny. I would kind of like to stay with the pack.
|
|
#
?
May 20, 2015 04:00
|
|
|
No strict schedule, things move as fast as people participle with questions or comments about what they've read.
|
|
#
?
May 20, 2015 04:25
|
|
|
insidius posted:How does the scheduling work? I want to buy it today but I have a tendency to blow through a book so quickly it aint funny. I would kind of like to stay with the pack. About a chapter a week, sometimes more. In all seriousness, if you don't have Linux experience, take it slow. Long term retention is gonna take doing it a few times, even if you get it right the first time.
|
|
#
?
May 20, 2015 04:36
|
|
|
Are we done with powershell already? I shelved it on day three for a variety of reasons. Anyways can someone post an Amazon link to the Linux book?
|
|
#
?
May 20, 2015 04:50
|
|
|
Anyone have Kindle Unlimited? Looks awesome, but I don't think newer tech books are on there.
|
|
#
?
May 20, 2015 05:03
|
|
|
For all the people who either don't care about Linux or know it well already, I'd like to put out Sidney Dekker's Field Guide to Understanding Human Error, which I consider to be a pretty important book for operations people, people managers, or anyone interested in figuring out why things are always loving broken.
|
|
#
?
May 20, 2015 06:10
|
|
|
And are we ever doing ipv6? Also in for the guide to human error as I slowly drift into management
|
|
#
?
May 20, 2015 06:28
|
|
|
Vulture Culture posted:For all the people who either don't care about Linux or know it well already, I'd like to put out Sidney Dekker's Field Guide to Understanding Human Error, which I consider to be a pretty important book for operations people, people managers, or anyone interested in figuring out why things are always loving broken. This is definitely on my todo list, heard great things.
|
|
#
?
May 20, 2015 17:55
|
|
|
TL;DR Reading: Sidney Dekker's The Field Guide to Understanding Human Error Chapter 1: The Bad Apple Theory In this chapter, Dekker explains the Old View of understanding error, one which is tied to an understanding that "human error" is responsible for failures. Dekker proposes that while operators make decisions that appear in retrospect to be obviously terrible and dangerous, there exists a deeper truth: we cannot understand these decisions in hindsight alone without understanding why the operators did what they did. If we want to understand the underlying causes of a failure, we need to understand not just the people at the controls, so to speak, but the context with which the operators worked within a larger system. Blaming "human error" and actually learning from failure are two mutually exclusive outcomes. The goal of an investigation should be to learn from failure, not to engage in a witch hunt (sidenote: this mirrors the systems thinking approach of business luminaries like W. Edwards Deming). Overspecifying procedures, in an attempt to create a foolproof algorithm to avoid future recurrence of a problem, is more likely to cause additional errors in the future than it is to provide a net benefit. Similarly, reprimanding operators for "human error" is likely to cause people to sweep deviations from procedure under the rug, as opposed to improving outcomes. Investigations should begin with the assumption that people want to do their jobs well; you have to understand why what people did made sense to them at the time. Choice quotes:
This was a good chapter, and a worthwhile read. Dekker harps on some of these points again a little too long in later chapters. We'll get to that. As an aside, if you've ever engaged in "five whys"-style troubleshooting while performing a root cause analysis, these can provide a good starting point, but often arrive at exactly the kind of conclusions this chapter warns against. Vulture Culture fucked around with this message at 06:32 on May 21, 2015 |
|
#
?
May 21, 2015 06:26
|
|
|
Chapter 2: The New View of Human Error This very short chapter slightly expounds upon several of the principles introduced in the preceding chapter. Dekker reiterates that human error is not the cause of failure, but an underlying symptom of a systemic cause that must be identified in order to increase the safety of the system. Safety is never the only goal of the system being operated: it is an operational requirement in service of meeting other business goals. (This should sound familiar to everyone who's ever tried to do security, business continuity, or other risk-management work.) Accidents are not caused by a breakdown of processes that are well-functioning; rather, any such process should be validated against the sum of the circumstances perceived and navigated by the operator. (This dovetails into Nassim Taleb's work on Black Swans, as well as Donald Rumsfeld's explanation of "unknown unknowns.") Failures are actually byproducts of normal work, and safety is something which has to be deliberately and constantly worked towards by the entire organization. "Human errors" should be viewed as an example of the systemic problems which can easily happen to anyone else in the future. Dekker reiterates that the solution to accidents is not to reflexively institute new procedures, because those procedures may deny someone the autonomy to deal safely with a complicated circumstance. Likewise, new technology designed to improve the system's safety may introduce new problems as or more quickly than it fixes old ones. (As anyone who's worked with a badly-designed clustering solution can tell you.) Choice quotes:
Vulture Culture fucked around with this message at 08:34 on May 21, 2015 |
|
#
?
May 21, 2015 08:29
|
|
|
Which edition of human error are you reading?
|
|
#
?
May 21, 2015 16:06
|
|
|
Tab8715 posted:Which edition of human error are you reading? http://www.amazon.com/Field-Guide-Understanding-Human-Error-ebook/dp/B00BL0OZ0E
|
|
#
?
May 21, 2015 16:56
|
|
|
Vulture Culture posted:As an aside, if you've ever engaged in "five whys"-style troubleshooting while performing a root cause analysis, these can provide a good starting point, but often arrive at exactly the kind of conclusions this chapter warns against. At DevOps Days Rockies last month, there was a session on postmortems. A guy from Etsy (not Allspaw) was there and very insistent that Five Why's is generally terrible. Because unless you're really being serious about not using the human error crutch, guess what? The root cause is always miraculously "Homeboy hosed up!" Or worse, one Why is "Homeboy hosed up!" and then the next Why is "because he is a dumb poo poo and should be fired". Which lets you completely cop out of actually learning or improving as a result of the incident. Contrast that with 1) The site went down. Why? 2) Database got corrupted and crashed. Why? 3) Docjowles failed over the master DB to the slave to conduct routine patching, and the new Master was out of disk space. Why? 4) Before being promoted to master, the Slave's disk had been full for the last month. Why? 5) A cleanup job that runs nightly on the master was never ported to the slave. Why? Because we don't use config management to keep everything in sync automatically. We should probably look into that! If you're doing O.G. root-cause analysis, you probably stop at #3 and say "lol loving Docjowles, that moron didn't even check if the disk was full". But I shouldn't have to. Walking back a few steps further to investigate why it was even possible for me to do the procedure wrong in the first place opens up a whole new way of managing the infrastructure. Which might never have been considered if I just got fired for crashing the site.
|
|
#
?
May 21, 2015 18:19
|
|
|
Docjowles posted:At DevOps Days Rockies last month, there was a session on postmortems. A guy from Etsy (not Allspaw) was there and very insistent that Five Why's is generally terrible. Because unless you're really being serious about not using the human error crutch, guess what? The root cause is always miraculously "Homeboy hosed up!" Or worse, one Why is "Homeboy hosed up!" and then the next Why is "because he is a dumb poo poo and should be fired". Which lets you completely cop out of actually learning or improving as a result of the incident. 6) Someone clearly understood during the post-mortem that configuration management was the right approach to produce repeatable server builds. Why weren't we already using it here? 7) Okay, so we are using configuration management pretty much everywhere, but this one change snuck into production because the cleanup job was a rush job added during an emergency. 8) Why are we adding maintenance jobs during an emergency? 9) Okay, this one was really important. But why didn't a ticket get created to backport the maintenance task into configuration management? 10) The engineer-on-call was really tired and forgot to create a ticket. Are we overworking our on-call engineers late at night? Is there something going on in Jim's personal life where we should give him a break from the on-call rotation for awhile? 11) By the way, should we invest in some mechanism to check for changes that aren't managed by configuration management? 12) Oh yeah, why weren't we monitoring the disk space again? It becomes pretty obvious that your "root cause analysis" is really starting to look more like a tree of disparate factors shoved into list form. Go deeper, and it's probably not even a tree anymore, but more like a weighted directed graph. The graph probably even contains cycles where you get feedback loops! The frustrating part is that if you don't do this, and you follow a single causal chain, you can still see improvements in system reliability! Because people see improvements, even though they aren't enough, people feel like they're doing postmortems correctly by using Five Whys. You're just attacking the problem from one angle and you'll have to do it again the next time the stupid thing falls apart for some other related reason. Vulture Culture fucked around with this message at 18:51 on May 21, 2015 |
|
#
?
May 21, 2015 18:41
|
|
|
Sheep posted:Are we done with powershell already? I shelved it on day three for a variety of reasons. The Powershell book is really good but 90% of time I can figure out what I need to do in Powershell already or just hack together existing scripts. Here's the RHEL Book RHCSA & RHCE Red Hat Enterprise Linux 7: Training and Exam Preparation Guide (EX200 and EX300), Third Edition Vulture Culture posted:This Kindle edition: That's the 06' version and there is a newer one but it's interesting so I'll pick it up.
|
|
#
?
May 22, 2015 02:30
|
|
|
|
| # ? May 5, 2024 14:17 |
|
|
Tab8715 posted:The Powershell book is really good but 90% of time I can figure out what I need to do in Powershell already or just hack together existing scripts. The RHC(SA|E) book arrived today and is huge. Maybe twice as large as the official training docs
|
|
#
?
May 22, 2015 03:41
|
|