Профессиональная деформация дело серьёзное. Чаще мы говорим про неё в негативном ключе, но в данный статье я собрал принципы которые мне лично в жизни сильно помогают.
И нет, я тут не буду писать про «как мы ставим друг другу задачи в Jira на помыть посуду или погулять с собакой». Речь скорее про принятие решений или использование привычек, приобретенных за время работы в IT сфере. Это сугубо мой опыт и ИМХО конечно, если покажется не релевантным – дизлайк доступен, комменты тоже (лучше комменты :)).
Правило 1. Стоимость владения надо учитывать.
У опытного ИТ директора в "библии" или в "букваре" черным по белому написано: "У любой системы\оборудования\технологии есть стоимость владения". Если вы внедряете систему или онбордите технологию, то для того, чтобы учитывать в бюджете её стоимость, нужно закладывать не только стоимость изначальной покупки, но и стоимость владения технологией ежегодно. В неё обычно входят затраты на обслуживание, поддержку, обновления и подобное.
Чем помогает в жизни:
В жизни мы почему то про этот принцип забываем. А ведь тут то же самое:
Умеете водить машину - надо регулярно водить иначе забудете как
Знаете английский – на нём надо регулярно разговаривать
Знаете C++, но не писали на нём код 3-5 лет… у меня для вас много новостей.
Ну и так далее. Только в отличие от компании у нас бюджет один – время, и он очень ограничен. Так что как пели в старой песне "Думайте сами, решайте сами, иметь или не иметь". Не факт что этот навык вам нужен. Или эта вещь и этот девайс. Сможете ли вы потом поддерживать его работоспособность, поддерживать и развивать? Точно стоит инвестировать время в его изучение? В детстве я учил всё подряд... Теперь это конечно очень сильно ложится на время.
Правило 2. Все ключевые элементы инфраструктуры должны иметь минимум 2-кратное резервирование
В ИТ это тоже «букварь» о котором мы даже не задумываемся. Кластеризация, HA, репликация, резервирование. Сложно представить себе Production систему без резерва.
Чем помогает в жизни:
Есть вещи от которых вы зависите: банковский счет, паспорт, кредитная карта, сотовый телефон. Потеря чего то из этого ведёт к неожиданным последствиям и выпаданию из жизни на какое то время. Очень часто мы не имеем резерва основных рабочих инструментов, документов или необходимых девайсов. Это неправильно, и хорошо бы о них не забывать. Купите второй телефон, ежедневные копии из основного в который можно будет восстановить, сделайте второй загран, несколько карточек разных банков в идеале разных стран, наличка, крипта. Всё это по сути простая жизненная необходимость, о которой мы часто забываем.
Правило 2.1 DR план обязателен
Вцелом оно просто продолжает правило 2. В ИТ у организации должен быть не только резервный сервер, но и резервный сервер в резервном ЦОД-е, удаленном от основного. План действий на случай потери целого ЦОД-а, потери ключевых людей в команде и ещё каких либо очень неприятных событий.
Чем помогает в жизни:
«тревожный чемоданчик» когда-нибудь слышали? Резервное место предполагаемого обитания. Резервный счет и т.п. Такой я бы сказал более существенный и длительный резерв, на случай прямо уже очень больших бед. Но как показывает практика, вероятность их в последнее время существенно выросла.
Правило 3. Собирай данные
Любая информация, несущая определенную ценность для процессов компании, должна быть зафиксирована. Крайне желательно в структурированном виде в соответствующей системе и БД. Из них строится аналитическая система для взвешенного принятия решений.
Чем помогает в жизни:
Заметки и задачи одна из основных ценностей. Если информация важна – запиши. Информация по которой нет поиска и\или аггрегации – бесполезна. При принятии решений важно ориентироваться не только на память но и на записи, память может вас подводить, вы не учтете всю доступную информацию и примете неверное субъективное решение.
Правило 4. Долгосрочное планирование с четкими этапами и сроками – миф. Только Agile.
В ИТ мы привыкли уже, что требования к проекту быстро меняются, ситуация меняется, человек не знает, чего хочет. Короткие итерации, регулярный пересмотр планов – это то, как мы обычно работаем.
Чем помогает в жизни:
Жизнь меняется также быстро, на самом деле. И если говорить о том, что мы что-то можем четко запланировать, то это чаще похоже на самообман. Для себя также принял, что менять планы - это нормально, принимать спонтанные решения - это нормально, корректировать планы если действительно чего то хочется или не хочется – тоже нормально. Вцелом, чем меньше барьеров для изменения чего то в жизни тем лучше.
Правило 5. «В штат» не всегда хорошо. Грамотное использование подряда и аутстафа – залог экономии бюджета.
Иногда возникает желание «сделать всё внутренней командой» и во многих случаях это правильно. Но любой ИТ директор, кто завершил хотя бы один проект, знает что если в команде нет каких то компетенций (ну, к примеру, DevOps нужен), то проще взять кого то на подряд или аутстаф, чем подбирать\растить компетенцию внутри, по крайней мере если нет загрузки по задачам как минимум на 2 человек (дада, опыт подсказывает что люди болеют, увольняются и ходят в отпуск).
Чем помогает в жизни:
Если есть выбор заниматься профильной или непрофильной деятельностью, то лучше всегда выбирать профильную. Время, которое мы тратим на уборку/готовку/передвижение можно сэкономить в случае если вы его можете потратить на свою основную деятельность (взять фриланс, усилить позиции по основной работе, взять коммерческий проект или pet project). В долгосроке это может получиться эффективнее, если делегировать непрофильную для вас деятельность службам клининга и доставщикам еды. Выполнять свою профессиональную деятельность можно намного эффективнее и вцелом в ней вы наверняка намного полезнее.
Правило 6. Минимизация простоев – ключ к эффективности.
Простой это плохо. Хороший ИТ директор или просто РП или ответственный за инфраструктуру знает. Да, резерв должен быть, да хорошо, когда есть свободные люди\мощности. Но с точки зрения эффективности, если человек или сервер ничем не занят – это затраты. Поэтому существенно лучше, когда задачи есть всегда, просто есть управление приоритетами. Приоритеты на встрече по наполнению в Scrum, вытесняющие задачи в Kanban, QOS-ы для сетевых серверах, приоритет процессов для процессора и т.п. Управление загрузкой - один из ключевых элементов менеджмента людей или оборудования. В ИТ мы к этому уже привыкли.
Чем помогает в жизни:
Думскроллинг – зло. Просто валяться на диване – естественно тоже зло. Загрузка головы на 100% достигается за счет параллельних задач. Если устал от чего то одного – переключись на другое. Сейчас, к примеру, с приоритетом я пишу эту статью, но в фоне смотрю видеокурс. Если нужно будет больше внимания на курс – я переключусь. При этом пока я печатаю фразу которую я обдумал за предыдущую секунду мне лично скучно и нечем заняться, в это время внимание поглощено курсом. Вместо соцсетей - библиотека книг всегда в мобильником. Новостные паблики строго отфильтрованы по темам которые мне интересны. Всегда под рукой тоже есть план курсов, который ещё корректируется и обновляется. Очень помогают аудиокниги и видеокурсы - в процессе когда ты не можешь читать глазами время можно использовать.
Правило 7. Сбор и анализ целевых метрик
«— Скажите, пожалуйста, куда мне отсюда идти?
— А куда ты хочешь попасть? — ответил Кот.
— Мне все равно... — сказала Алиса.
— Тогда все равно куда и идти, — заметил Кот.
— Только бы попасть куда-нибудь, — пояснила Алиса.
— Куда-нибудь ты обязательно попадешь, — сказал Кот. — Нужно только достаточно долго идти.»
Каждый продакт знает наизусть этот отрывок из "Алисы". Без метрик успеха и их сбора трудно достичь чего то в проекте. Также каждый специалист по инфраструктуре знает – без мониторинга и метрик у вас нет инфраструктуры :)
Чем помогает в жизни:
В жизни должны быть цели, хотя бы краткосрочные. Ставя себе цель надо спросить – «как я буду понимать что я стал ближе к цели». Сформулировав для себя те самые метрики. Каждый день должна быть возможность спросить себя – «насколько я сегодня стал ближе к своим жизненным целям». Если ответ - «ни насколько», значит или у вас был очень плохой день, или что то не то с целями, или сегодня я делал что то не то, это недопустимо – завтра я так делать не буду.
Правило 8. Стратегия отката
Транзакции, инструментарий IaaS, планирование развертывания в проектах, change management. Вообщем практически всё учит в ИТ этому правилу: «перед тем как внести изменение, продумайте как будете возвращать обратно, если оно окажется неудачным». Это база из баз опять же и пояснять тут даже особо нечего.
Чем помогает в жизни:
Эмоции - это плохо. Необратимые жизненные изменения - тоже плохо. Прежде чем что-то сделать, надо обдумать если данное изменение в жизни окажется неудачным смогу ли я вернуть всё назад и как лучше это сделать. А может сейчас надо как то подготовиться чтобы была возможность «отката изменений». Это правило учит не делать необдуманных решений, и более тщательно готовиться даже если идея кажется "очень выгодной" и нужно "прямо срочно". Сколько раз меня это правило спасало наверное даже не сосчитать :).
Правило 9. Регулярный Maintenance надо учитывать и планировать
Для любого ИТ специалиста это в принципе очевидно. Сервера иногда надо останавливать, кулеры менять, пыль убирать. В СУБД надо индексы дефрагментировать, статистики перестраивать, кэши сбрасывать. В системах надо ротировать логи, проводить проверки безопасности и валидации DR планов и копий, да много чего ещё. Чтобы система работала дольше без внеплановых падений и более стабильно.
Чем помогает в жизни:
Не секрет, конечно, что у всего есть свой срок службы. К сожалению, и у нас тоже. И поскольку наша система работает строго 24x7, то обслуживание кране затруднено. Но, как минимум, регулярная диагностика – это важный элемент, который должен быть на системной основе. Своевременные корректировки способны продлить нам срок службы, порой весьма существенно. И хотя правило из разряда «спасибо КЭП», но оно самое важное в списке, пожалуй. Берегите себя.
Ну и конечно подписывайтесь на мой канал, если вдруг понравился подобного рода контент: https://t.me/comol_it_does_matter
