Мыслить как Айтишник

В любой специальности надо думать определенным образом. В IT надо думать как Айтишник. В этом посте разберем некоторые аспекты мышления.

Визуальное мышление

Обычно есть два типа мышления. Текстовое это когда в голове представляешь все в виде текста. Визуальное это когда моделируешь в уме что либо. К примеру, если надо написать скрипт, то надо представлять себе его алгоритм. Представить можно в виде блок-схемы как учат в ВУЗ’ах или представить в виде скажем трехмерных моделей серверов с которыми он должен взаимодействовать и все что оно будет делать. Это позволяет моделировать в уме поведение скрипта т.е. можно проводить некоторые мысленные эксперименты. Скажем стоит задача поднять локальную сеть в новом офисе. Прежде чем начинать работу необходимо спроектировать эту сеть. Для этого надо прикинуть сколько будет отделов, сколько рабочих мест, как будут распологаться посадочные места, что и как можно автоматизировать (например с использованием интернета вещей), где должны висеть IP-камеры, сколько личных гаджетов будут использовать сотрудники и т.д. Исходя из этого можно определиться с тем какую сетевую маску использовать т.е. решить какого размера будет сеть и сколько хостов примерно будет в него входить и как вообще монтировать СКС. Любая современная сеть использует виртуальные сети (VLAN). Здесь тоже необходимо визуально представлять себе как будет разбита сеть на VLAN домены, как будет да и вообще надо ли коммутировать или маршрутизировать трафик между ними. Вообщем нюансов куча и легче всего визуально представлять все эти дела и проводить мысленные эксперименты задавая себе вопросы типа «что будет, если произойдет это» или «что будет, если сделать так то». Определившись со всеми этими вопросами уже можно приступать непосредственно к реализации задуманного.

Закон Мерфи

Обычно начинающий Айтишник слышит о том, что у кого-то там деградировался RAID массив и потерялась вся информация, но при этом сами ничего не предпринимают думая, что «это произошло с ними, а я это я и со мной такое не произойдет». Реальность же говорит нам «что может произойти, то и произойдет», что подтверждает теория вероятности. Если закупили коммутатор, то заодно закупите резервный и лучше точно такой же модели, чтобы при возникновении проблем быстро восстановить конфигурацию из резервной копии минимизируя даунтайм или задействовать сразу оба устройства, чтобы один дублировал другой, тогда вообще не будет даунтайма, но все это конечно довольно жирненько в финансовом плане, особенно если устроились работать в молодую компанию. В этом случае компания рано или поздно либо обанкротится либо придет к успеху, так что важно не забывать об этом. Смысл в том, чтобы свести к минимуму возможность возникновения проблем поскольку предусмотреть все не получится. Правило простое, но сэкономит кучу нервных клеток.

Приоритеты

Порой приходится решать несколько задач одновременно и тут успех довольно сильно зависит от приоритетов, которые приходится раздавать задачам. Тут я использую так называемые «весы» т.е. взвешиваю все за и против, таким образом получаю вес задач и начинаю работать над весомой задачей, когда как менее весомая может подождать. Например представим, что одновременно упали сервер сборки программ и сервер приложений 1С. Тогда начинаем думать следующим образом. Программистам надо работать. +1 вес к серверу сборки. Бухгалтерам тоже надо работать. +1 к серверу приложений.
Сервер сборки: 1
Сервер приложений: 1
Программисты должны получать зарплату, а без бухгалтеров это нереально. +1 к серверу приложений.
Сервер сборки: 1
Сервер приложений: 2
Проведем поверхностный анализ поломок. Сервер сборки упал потому, что было добавлено неправильное правило фаервола, а сервер приложений упал потому, что вышел из строя один из жестких дисков, что перевело работу файловой системы в режим read only. +1 серверу сборки и -1 серверу приложений.
Сервер сборки: 2
Сервер приложений: 1
Таким образом сперва чиним сервер сборки и программисты счастливы, а поскольку починка сервера приложений так итак займет много времени, то беремся за него после быстрорешаемой проблемы.

Поиск и анализ информации

Обычно люди любят задавать вопросы, чем сильно достают хотя казалось бы есть поисковики, где можно найти любую информацию. Некоторые вообще брезгают поисковиками думая, что раз они пользуются ими значит они лузеры ничего не знающие. На самом деле знания приходят с опытом, а чтобы их наработать надо уметь находить информацию и анализировать ее. В ВУЗ’ах особо не учат тому же программированию или настройке систем поскольку все чему там научат уже будет не актуальным когда вы выпуститесь. Потому там учат самостоятельному поиску и усвоению информации т.е. учат учиться и это я считаю правильным подходом. Именно поэтому при наборе кадров смотрят на наличие диплома поскольку его наличие указывает на то, что человек имеет предрасположенность к самообучению, что очень важно в айтишном деле. Тут у некоторых может возникнуть вопрос «какой поисковик лучше использовать?». Ответ прост как и сам вопрос — Google. Когда я сталкиваюсь с какой либо проблемой например с настройкой программного обеспечения, то иду читать блоги и форумы по теме. Важно не опираться только на один источник информации поскольку проблемы бывают разные и решаются они по разному, а чтобы понять как решить проблему надо понимать как работает программа, потому и надо читать множество источников.

Мнемотехника

В айтишном деле приходится использовать очень много различных паролей, а их как-то надо запоминать. К примеру я использую очень простую технику смысл которого в том, чтобы сопоставлять цифрам буквы. Рассмотрим несколько примеров сгенерированных на pwgen паролей:
lei5ZaeP — лейСзаеП
Ke9eiSee — КеДейСи
Wuro0Oxu — ВуроООху
Это сильно упрощает запоминание паролей и отпадает необходимость в использовании всяких дырявых менеджеров паролей. Обычно когда генерирую пароли, то с первого раза не получается поскольку ищу такие пароли, которые были бы созвучны с какими-то словами или просто легко запоминались. Если надо использовать в пароле заглавные буквы, то обычно делаю заглавной первую букву.

Контроль

Довольно важно держать под контролем как версии программ, так и локальную сеть и прочее. Потому такие вещи как NGINX, PHP, MongoDB предпочитаю собирать из исходных кодов. Это позволяет не ждать когда в репозиториях обновятся эти программы, также если используете HVM виртуализацию, то получаете максимальную оптимизацию под систему и можно не обновлять дистрибутивы постоянно, а просто обходиться сборкой нужных версий программ. Возможно это неважно, если работаете в каком нибудь государственном учреждении, но сильно пригодится, если вы работаете в компании, которая зарабатывает на разработке программного обеспечения. В плане локальной сети важно использовать систему агрегации логов вроде Wazuh, который позволит своевременно реагировать на странное поведение операционных систем (как правило в следствии заражения вирусами), так и визуализировать атаки на сервера благодаря чему можно принять соответствующие меры. Антивирусы конечно круто, но совсем не круто если вы занимаетесь разработкой ПО поскольку они довольно сильно влияют на производительность системы, а программистам не охота сидеть до полуночи пока скомпилируется тот или иной билд ПО, а если нет возможности отлавливать зловреды в реальном времени, то надо работать над предотвращением заражений, чего и можно добиться за счет контроля.

Абстракция

Старайтесь асбтрагироваться от вещей. Например, когда задаете имя компам в сети, то не задавайте каких-либо осмысленных названий скажем по имени и фамилии пользователя. Сотрудники бывают увольняются, а техника передается из рук в руки, потому лучше именовать скажем по местонахождению офиса и какие-нить префиксы вроде SPB-001. Тоже самое относится и к серверам. Не стоит им задавать имена вроде dhcpd, dns, domain controller и т.д. поскольку в современном мире все серверы многоцелевые особенно если используются микросервисы. Скажем когда начинают монтировать локальную сеть, то некоторые начинают обзывать розетки и описания портов на коммутаторе в духе BUH1 или HR2 и т.д. однако таким образом создается только дополнительная работа когда меняется назначение кабинетов. Потому лучше при маркировке абстрагироваться от всего этого и поделить все пространство на зоны и маркировать согласно названию зон что-то в духе A1, B2 и т.д. тогда будет пофиг кто куда переехал.

Архитектура и алгоритмы

Не секрет, что каждый системный администратор в душе еще и немного программист. Потому он ну вот прям должен знать хотя бы основы архитектуры программ и алгоритмы. Рассмотрим случай когда системному администратору надо провести аудит безопасности, но чтобы провести его надо понимать как работает программа над которой и надо провести аудит безопасности. Вот тогда и начинается разбирательство того как программа работает ведь сейчас уже одна программа не является одной программой, а является комплексом программ и это наверняка хорошо знают веб-разработчики или те кто работают с nix системами. Тут оказывается, что программа состоит из нескольких программ, которые общаются друг с другом по определенным протоколам, которые ожидают определенные команды или последовательность байт и вот тогда и начинается сканирование различных портов, перехват трафика и прочее. Поэтому очень важно разбираться в архитектуре программ. Далее в ходе работы любого админа становится все больше рутинных задач вроде регистрации и блокировки пользователей, составления каких-то отчетов, отправки каких-то писем и прочее. Тут-то и выходят на сцену алгоритмы. Возьмем самый простой пример когда надо отправлять письмо каждый раз когда в Active Directory блокируют пользователя. Весь пример для простоты будет на псевдокоде близком к PHP:

#выполняем подключение
$db = connect.ldap('user','pass','192.168.1.9','398','cn=Users,dc=ad,dc=example,dc=com');
#создаем пустой массив
$users = array();
#получаем список всех пользователей
$users = $db->user()->all();
#создаем функцию которая будет возвращать true если пользователь заблокирован
function user_disabled($user){
	#ищем пользователя по аттрибуту samaccountname
	$result = findBy('samaccountname',$user);
	#если если вместо его имени возвращаетяс код ошибки 66050 значит пользователь заблокирован и возвращаем true
	if($result == 66050){
		return true;
	}
	return false;
}
#каждый элемент массива $users впихиваем в переменную $user в цикле
foreach($users as $user){
	if(user_disabled($user)){
		#если функция user_disabled возвращает true то отправляем письмо админу
		mail('admin@example.com', 'User disabled', $user.' has been disabled!');
	}
}

Довольно простой алгоритм. Давайте возьмем что-нить посложнее. Предположи у нас есть 1 000 000 пользователей и нам надо найти одного пользователя с ID = 777 и если вы начнете искать этот ID путем сравнения что-то вроде:

$userID = 777;
$users = sizeof($users);
for($users; $users <= $userID; ++$users){
	if($users == $userID){
		return true;
	}
	return false;
}

Вы просто заколебетесь ждать когда отработает этот код. Вместо этого можно определить минимум и максимум т.е. минимум у нас 0 и максимум это 1 0000 000. Тогда делим максимум на 2 и получем середину. Далее проверяем меньше или больше:

$min = 0;
$max = sizeof($users);
$mid = $max/2;
if($mid > $userID){
	for($mid; $mid <= $userID; $mid++){
		if($mid == $userID){
			return true;
		}
	return false;
}
if($mid < $userID){
	for($mid; $mid >= $userID, $mid--){
		if($mid == $userID){
			return true;
		}
	return false;
}

Таким образом мы ускорили поиск пользователя в 2 раза. Также можно попытаться определить является ли $userID четным или нечетным и если четный, то например выкинуть все нечетные числа из $mid. Тогда получим троекратное ускорение поиска.

Вывод:

Системное администрирование специальность довольно специфичная. Надо знать много всего, но поверхностно начиная от дел управленческих заканчивая программированием и если вы шли на эту специальность ожидая, что будете на расслабоне гонять контру, то явно ошиблись)