Skip to content
Permalink
Browse files

09/10 add break, remove duplicate

  • Loading branch information
markus2330 committed Jun 12, 2019
1 parent 7622e90 commit 5118d3419638b534f0690d7bb8798874ae51ea0f
Showing with 19 additions and 197 deletions.
  1. +5 −5 slides/08.tex
  2. +14 −7 slides/09.tex
  3. +0 −185 slides/10.tex
@@ -243,11 +243,11 @@ \subsection{}
\end{itemize}
\end{frame}

%\begin{assignment}
% \begin{task}
% Break.
% \end{task}
%\end{assignment}
\begin{assignment}
\begin{task}
Break.
\end{task}
\end{assignment}

\begin{frame}
\frametitle{Push vs.\ Pull}
@@ -1,8 +1,4 @@
%TODO: how to make error messages shorter
%TODO: more didactics (team work, ..)
%TODO: learning outcomes
%TODO: error should be first, warning: user view is duplicated in slides 10
%TODO: distributed vs. centralized

\input{setup}

@@ -77,8 +73,8 @@
\item[3] {\color{gray} config-less systems}
\item[2] secure conf
\item[2] {\color{gray} architectural decisions}
\item[1] {\color{red} push vs.\ pull}
\item[1] {\color{red} infrastructure as code}
\item[1] {\color{amethyst} push vs.\ pull}
\item[1] {\color{amethyst} infrastructure as code}
\item[1] {\color{red} full vs.\ partial}
\item[1] convention over conf %iguration
\item[1] CI/CD
@@ -87,6 +83,16 @@
\end{multicols}
\end{frame}

\begin{frame}
\frametitle{Learning Outcomes}
Students will be able to
\begin{itemize}
\item connect needs of CM tools with configuration specifications.
\item remember differences between different CM languages.
\item contextualize CM languages with the view point of administrators.
\end{itemize}
\end{frame}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Recapitulation}
@@ -796,7 +802,8 @@ \subsection{}
\begin{itemize}[<+-| alert@+>]
\item Configuration management languages differ widely.
\item Configuration specifications are helpful in different ways.
\item Building your own tools might be efficient.
\item Do not design around tools but design tools around you.
\item Outlook: Go more in-depth into CM languages, contextualize with our topics
\end{itemize}
\end{frame}

@@ -80,191 +80,6 @@


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{User View}

\subsection{}

\begin{frame}
\frametitle{User View}

Who is the user of CM?

\begin{itemize}[<+-| alert@+>]
\item End Users?
\item Developers (devs)?
\item System Administrators (admins)?
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{System Administrator Research}

\begin{itemize}[<+-| alert@+>]
\item Interest of understanding administrators emerged around 2002~\cite{anderson2002researching}.
\item Typical methods are surveys, diary studies, interviews and observations (ethnographic field studies).
\item Field studies also done in industry \cite{barrett2004field}.
\item Barrett \cite{barrett2003system} tried to initiate a workshop at CHI 2003 to draw the attention of the HCI community towards system administration.
\item The workshop was already dropped in the next year.
\item The tenor is that ``tools ... are not well aligned''~\cite{haber2007design}.
\item Research mainly looks at pre-CM. Manual administration is still standard (Source: e.g., Luke Kanies).
\end{itemize}
\end{frame}


\begin{frame}
\frametitle{CM research}

In the meanwhile at Large Installation System Administrator Conference (LISA):

\begin{itemize}[<+-| alert@+>]
\item began as CFengine Workshop at LISA 2001
\item CM workshop by Paul Anderson~\cite{anderson2002researching}
\item in LISA 2003 an informal poll asked about CM tools: \\
the only user of each tool in the room at the time was its author~\cite{burgess2006modeling}
\item it is easy to invent CM tools (and configuration file formats)
\item it is difficult to make it useful beyond your own goals
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Tasks}

What do system administrators do?

\begin{itemize}[<+-| alert@+>]
\item keep our infrastructure running
\item coordinate
\item do backups
\item manage hardware
\item do inventory
\item install applications
\item manage security
\item configure applications
\item troubleshoot
\item $\implies$ the unsung heroes!
\end{itemize}
\end{frame}


\begin{frame}
\frametitle{7 people, 1 command-line~\cite{barrett2004field}}

\begin{itemize}[<+-| alert@+>]
\item system administrator misunderstood problem \\ (had a wrong assumption)
\item 7 people sought attention and trust, competing to tell the admin what to do
\item due to wrong assumption the admin communicated to everyone, people could not help
\item there were several instances in which the admin ignored or misinterpreted evidence of the real problem
\item eventually someone else solved the problem: admin confused ``from''/``to'' port in the settings and firewall blocked requests
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{other cases~\cite{barrett2004field}}

\begin{itemize}[<+-| alert@+>]
\item lost semicolon: execution of script failed due to missing semicolon, then they tried to delete a non-existent table.
\item crontab: onltape/ofltape confused because of discussion about offline backup (although an online backup should be performed).
\item crit sit: many system administrators competed against each other trying to write a simple script. The crit sit continued for two weeks.
\end{itemize}
\end{frame}


\begin{frame}
\frametitle{\citet{haber2007design}}

Later \citet{haber2007design} repeated an ethnographic field study.
The stories are similar to \citet{barrett2004field}.
Their study was also conducted in the same company.
They created personas:

\begin{itemize}
\item database administrator
\item web administrator
\item security administrator
\end{itemize}
\end{frame}



\begin{frame}
\frametitle{Database Administrator~\cite{haber2007design}}

\begin{itemize}[<+-| alert@+>]
\item frequent contact via phone, e-mail and IM
\item needs to work on weekends
\item pair-programming for new tasks
\item typical errors: stopping wrong database process
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Web Administrator~\cite{haber2007design}}

\begin{itemize}[<+-| alert@+>]
\item crit sit
\item deploying new Web applications
\item about 20-400 steps to deploy an application
\item moving from test to production done by hand
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Security Administrator~\cite{haber2007design}}

\begin{itemize}[<+-| alert@+>]
\item gets emails on suspicious activities
\item multi-user chat
\item ad-hoc scripts
\end{itemize}
\end{frame}


\begin{frame}
\frametitle{\citet{haber2007design}}

\begin{itemize}[<+-| alert@+>]
\item ``if data is lost...that is when you write your résumé.''
\item \p{90} is spent with communicating with other admins
\item \p{20} of the time is spent in diversions~\cite{barrett2004field}
\item \p{20} of the time people communicated about \emph{how to communicate}~\cite{barrett2004field}
\item \p{6} is gathering information and running commands
\item quality control: monitoring found that non-functional service was down two days
\item CLIs were generally preferred
\item configuration and log files are scattered, poorly organized and often used inconsistent terminology
\end{itemize}
\end{frame}


\begin{frame}
\frametitle{Findings \cite{barrett2004field}}

\begin{itemize}[<+-| alert@+>]
\item syntax checking is essential
\item replicating actions (e.g., to production) is error-prone
\item undo not available
\item do not assume a complete mental model (``if understand the system is a prerequisite [...], we are lost'')
\item do not assume programming skills (only \p{35} reported having a bachelor's degree)
\item trust in CLI tools but little trust in GUIs (is the information up-to-date?)
\item errors while executing scripts lead to inconsistent state, rerunning often does not work (if not idempotent)
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Design Principles \cite{haber2007design}}

Many design principles for tools were given~\cite{haber2007design}:

\begin{itemize}[<+-| alert@+>]
\item configuration and logs should be displayed in a uniform way
\item APIs/plugins for tools should be provided
\item errors in configuration need to be discovered quickly
\item confusion of similar settings should be avoided: add links, explain interactions
\item provide means of comparing configuration settings
\item provide consistent profiles of information
\item both transient and persistent settings should be visible
\item when errors occur: always display which changes have been made (modern approach is idempotence)
\end{itemize}
\end{frame}



0 comments on commit 5118d34

Please sign in to comment.
You can’t perform that action at this time.