Нас часто спрашивали, почему только языки программирования? Как на счет других специальностей в IT? Что делать, если я достаточно хорошо программирую, вырос до senior разработчика и понял, ... что управлять мне нравится сильно больше, чем программировать?
Мы вас услышали! И подготовили курс для тех, кто хочет стать хорошим управленцем в сфере IT. Курс затрагивает такие интересные вопросы как правильное взаимодействие с заказчиками, управление изменениями, организацию процессов и финансы. Познакомьтесь с программой сами: http://otus.ru/lessons/it-menedzher/?utm_source=telegram&utm_medium=internal&utm_campaign=itsm&utm_term=welcome Насколько эти темы могут быть интересны - вы скоро оцените сами - ведь мы собираемся выпустить несколько #deeppost на тему IT management.
В общем, мы так рады запуску нового курса, что как только открыли возможность прохождения вступительного тестирования - побежали едва ли не всей компанией проверять свои знания :)
А вы?

#deepjava #otus

О чем говорят логи Garbage Collector

Наверняка вы слышали, что сборщик мусора в Java может оказывать значительное влияние на производительность приложения. Многое может зависеть от типа сборщика и его настройки. Есть много инструментов для того, чтобы мониторить различные параметры сборки, но иногда достаточно внимательно посмотреть на логи, которые пишет GC. В этой заметке я расскажу, как выглядят логи, которые пишет сборщик мусора и что с помощью них можно понять о работе вашего приложения. Для начала, нужно запустить JVM, указав специальные параметры:


-XX:+PrintGCDetails - печатать детали о событиях сборки мусора
-XX:+PrintGCDateStamps - также печатать timestamp этих событий
-Xloggc:/home/otus/gc.log - опционально можно указать, в какой файл будут писаться логи, чтобы отделить их от логов вашего приложения.

Сборщики мусора SerialGC, ParallelGC, ConcurrentMarkSweepGC (CMS) разбивают память (хип) java-приложения на несколько регионов. Это Eden+Survivor1+Survivor2 - молодое поколение и Tenured - старое поколение. Сборщик GC1 устроен иначе и его стоит рассматривать отдельно.

Сборки мусора могут происходить только в молодом поколении - Minor GC или во всех регионах - FullGC. Давайте посмотрим на логи на примере ParallelGC (-XX:+UseParallelGC)


В этих логах отображено 3 сборки мусора, сначала 2 minor, затем full:

2017-09-17T21:03:30.200+0300: 0,449: [GC (Allocation Failure) [PSYoungGen: 3662K->336K(4608K)] 3662K->3408K(15872K), 0,0020199 secs] [Times: user=0,01 sys=0,00, real=0,01 secs]
2017-09-17T21:03:30.506+0300: 0,755: [GC (Allocation Failure) [PSYoungGen: 3652K->400K(4608K)] 6724K->6544K(15872K), 0,0021768 secs] [Times: user=0,01 sys=0,00, real=0,00 secs]
017-09-17T21:03:30.815+0300: 1,064: [Full GC (Ergonomics) [PSYoungGen: 400K->0K(4608K)] [ParOldGen: 9216K->9581K(18944K)] 9616K->9581K(23552K), [Metaspace: 3570K->3570K(1056768K)], 0,0047284 secs] [Times: user=0,00 sys=0,00, real=0,01 secs]

2017-09-17T21:03:30.200+0300 - сперва идет timestamp - абсолютное время, когда сборка была начата, затем время относительно старта приложения (0,449)

GC (AllocationFailure) - укзаывает, что это минорная сборка, при полной сборке будет указано Full GC. Причина начала сборки: не удалось выделить (allocate) место под новый объект

PSYoungGen - тип сборщика. PSYoungGen - это сборка молодого поколения в ParallelGC. Также вы можете встретить DefNew - сборка молодого поколения в SerialGC, ParNew - сборка молодого поколения CMS

Дальше идет самая интересная с практической точки зрения часть - занятая память до и после сборки по регионам:

[PSYoungGen: 3662K->336K(4608K)] - В молодом поколении до сборки было 3662K, после - 336K. Всего в регионе доступно памяти - 4608K

3662K->3408K(15872K) - Статистика по всему хипу, доступно 15872K. И здесь мы видим интересный момент, что в молодом поколении освободилось 3326K, а общее место в хипе уменьшилось только на 3662 - 3408 = 254К. Это означает, что часть объектов были перемещены из молодого поколения в старое (promoted).

Сборка заняла 0,0020199 secs

Для FullGC в логах видно статистику по всем регионам памяти, так как сборка запускается и в молодом и в старом поколении.

[PSYoungGen: 400K->0K(4608K)] [ParOldGen: 9216K->9581K(18944K)] 9616K->9581K(23552K), [Metaspace: 3570K->3570K(1056768K)], 0,0047284 secs]


[Times: user=0,01 sys=0,00, real=0,01 secs]
User - user-space время (операции вне ядра ОС), затраченное на GC
Sys - kernel-space - время, затраченное на системные вызовы ОС
Real - реальное время от начала и до конца сборки мусора. В нем учитывается, то время, пока процесс был прерван ОС или заблокирован (например, на IO)

При использовании параллельной сборки User-space время может быть больше чем real-time, потому что user-space будет суммироваться по всем CPU, на которых исполнялась сборка.

Вооружившись этими знаниями, вы сможете в рантайме смотреть за поведением GC и определить, не выросли ли паузы или количество FullGC. Как используется память вашего приложения и как объекты перемещаются между регионами памяти. Понимание этих процессов дает возможность более вдумчиво подойти к настройке вашего приложения.

Это малая толика того, что наши преподаватели будут разбирать на наших курсах по Java. Да, не забывайте о том, что их теперь два вида: наш изначальный онлайн-курс на 5 месяцев и оффлайновые курсы при МАИ, где вы сможете получить ещё сертификат о повышении квалификации государственного образца https://otus.ru/promo/java-2017/?utm_source=telegram&utm_medium=internal&utm_campaign=java&utm_content=deeppost&utm_term=19.09

#deepjava #otus
Принято считать, что многопоточность (multithreading) одна из самых сложных тем в программировании. И мы решили посвятить ей не одну, а несколько заметок, которые вы сможете найти по хэштегу #deepjava.

В этой заметке мы разберем типы ошибок многопоточного доступа к данным: race condition и memory consistency errors.

Но, перед тем как обсуждать ошибки доступа, давайте сначала разберем, что такое многопоточный доступ к данным. В какой именно ситуации можно получить такие ошибки.

Мы уже упоминали в предыдущем посте, что поток в Java это объект. У любого объекта есть класс. В классе могут быть методы и переменные. Представьте, что у вас есть класс — наследник от Thread, в котором вы в одной из переменных храните ссылку на массив. И этот массив вы получаете в конструкторе класса.

Пусть теперь, в runtime вы создаете два объекта рассмотренного выше класса и передаете в оба один и тот же массив. К элементам этого массива вы можете обращаться в методах run() ваших объектов. Одновременно. Из разных потоков исполнения. Вот это и есть многопоточный доступ к данным которые хранит массив.
Например, один поток может писать что-то в массив, а другой читать из него.

Рассмотрим теперь ситуацию, когда два рассмотренных выше потока собираются увеличить значение числа, которое записано в первой ячейке массива. Со следующей последовательностью событий: первый поток прочитал значение и увеличил его, второй поток прочитал то же значение, первый записал новое, второй увеличил значение и записал его. В результате вместо ожидаемого увеличения значения на 2 мы получим увеличение на 1, так как результат работы первого потока был “перетерт” результатом работы второго. Такая ситуация происходит из-за неатомарности операции увеличения значения числа. И является разновидностью ошибки многопоточного доступа — race condition.

Вторая возможная ошибка многопоточного доступа — memory consistency error происходит из-за того, что разные потоки могут быть физически исполнены на различных процессорах вашего компьютера. Каждый процессор может закэшировать значение переменной у себя, не записывая ее в общую память. В результате разные потоки могут видеть в одно и тоже время разное значение переменной.

Описанные выше проблемы призвана решить Java Memory Model. Что это такое и как именно она может помочь разработчику, мы рассмотрим в следующих заметках. И, подробно разберем на занятиях курса “Разработчик Java” в OTUS о которых вы можете узнать подробнее перейдя по ссылке:
otus.ru/promo/java-2017/?utm_source=telegram&utm_medium=internal&utm_campaign=java&utm_content=deeppost&utm_term=27.09

#java #otus
И вновь мы хотим порадовать Вас безумно интересной статьёй, но на этот раз о #java
https://habrahabr.ru/company/otus/blog/338770/

Нас спрашивали, когда же будут Дни открытых дверей на курсе Java. Мы долго молчали, потому что готовили для вас небольшой сюрприз: в этот раз будет аж 3 Дня открытых дверей!
👉 4 октября (уже в эту среду!) - поговорим о наборе на курс очного обучения Java.
👉 7 октября (в субботу) поговорим о нашей классической Java, которая так полюбилась нашим пользователям.
👉 11 октября (в среду) вновь поговорим про очное обучение Java.

Регистрируйтесь на мероприятие - будет интересно! Ведь отвечать на ваши вопросы и рассказывать о курсе будет Виталий Чибриков 🌟

По доброй традиции мы приготовили подарки: разыграем бесплатные места на курсе среди тех, кто успешно прошел вступительное тестирование 🎁
❗️А вот если вы успешно прошли вступительный тест по Java, но не указали свой город - самое время это сделать! Ведь если для онлайн обучения локация не имеет значения (учиться можно из любой точки мира), то офлайн обучение мы разыграем среди тех, кто прошел тест и выбрал своим городом столицу нашей Родины :)

Да прибудет с вами успех во время розыгрыша!
https://otus.ru/dod/?utm_source=telegram&utm_medium=internal&utm_campaign=java&utm_term=dod

Приглашаем всех на День открытых дверей посвящённый курсу "Разработчик Java (очно в МАИ)".
Трансляция начнётся через десять минут: https://www.youtube.com/channel/UCetgtvy93o3i3CvyGXKFU3g/live

#deeplinux #otus
Мы запускаем серию заметок по теме нашего нового курса “Администратор Linux”, которые вы сможете найти по хэштегу #deeplinux.

В жизни любого админа есть много пространства для автоматизации.
Пишем простенькие bash-однострочники типа:

for host in hostA hostB hostC; do ssh $host do_something_useful.sh; done

потом эти однострочники обрастают жирком, появляются всякие условия

dumpDb (){
case $DBKIND in:
mysql)
mysqldump $1
;;
pgsql)
pg_dump —some-option-to-dump-to-stdout
;;
esac
return $?
}
doBackup (){
dumpDb mydb > file.sql
return $?
}

doBackup && gzip file.sdl || exit 1

дальше - больше, появляются массивы, ассоциативные массивы и т.д. Но это еще цветочки. Хуже когда в скриптах появляются спонтанные вкрапления Python и Perl. Это свидетельствует только о двух вещах, о них - ниже.

Гвозди надо забивать молотком, а гайки крутить - гаечным ключом. Необходимо выбирать инструмент соответствующий задаче. Да, на баше можно писать достаточно сложные программы, но не стоит забывать, что, все же его задача - помогать нам в ежедневной работе. Скрипты на баше должны быть простые и понятные. Если вы написали скрипт который через неделю уже понимаете с трудом и, чтобы понять, что там происходит приходится интерпретировать скрипт в голове, то вы выбрали не тот инструмент или, что хуже, изобретаете велосипед.

Старайтесь правильно выбранным инструментом писать поддерживаемый код. Задумайтесь, ведь задача админа не в том, чтобы быть незаменимым, а в том, чтобы поддерживать работу системы, бесперебойную работу. Людям свойственно менять работу и оставлять после себя неподдерживаемый продукт значит портить себе карму. Даже если вы не собираетесь менять работу - в отпуск же вы собираетесь, да и отдел растет наверняка, сомневаюсь, что вам хочется всю жизнь поддерживать ваши скрипты. Ведь можно же поделиться с кем-то знаниями и двигаться дальше. Для этого надо прикладывать все усилия, чтобы ваш код был поддерживаем и читаем, использовать принципы KISS и YAGNI.

Это – только часть приятных бонусов.
Если захотите больше – добро пожаловать на курс “Администратор Linux”.
https://otus.ru/lessons/linux/?utm_source=telegram&utm_medium=internal&utm_campaign=linux&utm_content=deeppost&utm_term=05.10

Приглашаем всех на День открытых дверей посвящённый курсу "Разработчик Java".
Трансляция начнётся через десять минут: https://www.youtube.com/channel/UCetgtvy93o3i3CvyGXKFU3g/live

"Кто владеет информацией, тот владеет миром" - наверняка вы не раз сталкивались с этой цитатой Б. Ротшильда, основателя одной из влиятельнейших на сегодняшний день династий предпринимателей, и его суть как нельзя применима к нашему новому курсу “Разработчик Big Data”.
Что же такое Big Data? В глобальном смысле это проблема, и ее решение это не профессия, жестко закрепленная учебной программой, а профессионал, обладающий гибким набором компетенций и практик, позволяющих структурировать и управлять массивом данных.
Именно такого профессионала уровня middle/senior и призван подготовить наш новый курс.
Преподавателем курса станет Ксения Стройкова - программист отдела анализа данных в департаменте рекламных технологий Mаil.ru. Занимается разработкой и внедрением процессов и моделей по обработке данных для использования в рекламе,участвует в разработке хранилища данных для использования в рекламных сервисах, разработке системы для сегментирования аудиторий. Преподает курс “Алгоритмы интеллектуальной обработки больших объемов данных” в Техносфере Mail.ru Выпускница проекта Технопарк Mail.Ru Закончила МГТУ им. Н. Э. Баумана по специальности программное обеспечение ЭВМ и Информационные технологии.
Если ты давно тянешься к прекрасному миру больших данных, присоединяйся к новой группе!
Мы открыли вступительное тестирование для желающих проверить свои знания прямо сейчас.
https://otus.ru/lessons/BigData/?utm_source=telegram&utm_medium=internal&utm_campaign=bigdata&utm_term=welcome

#otus #deepmanager #deepitsm
Давайте поговорим сегодня о KPI?
Рано или поздно каждый сотрудник сталкивается со аббревиатурой «KPI». Для кого-то столкновение бывает приятным (от KPI зависит премия, которую реально получить), для кого-то – наоборот (от KPI зависит зарплата, которую руководители зажимают). Посмотрим на KPI не с точки зрения жертвы, а с позиции менеджера.
KPI устанавливают для того, чтобы можно было оценить результаты работы сотрудника, подразделения, отдельного процесса или качество предоставления ИТ-услуг. То есть KPI – управленческий инструмент. Сам по себе он пользы не несёт, только если есть какая-то задача: нужно понять, что именно требует измерения, зачем и как. И только потом измерять и делать выводы.
По нашему опыту, увлекаясь налаживанием управления, многие компании сталкиваются со следующей проблемой: как придумать нужные KPI? Как придумать целевые значения, которых нужно достичь или достигать? Ведь можно столько всего измерить! Например, при работе с инцидентами можно поставить KPI и на число поступающих заявок, и на число заявок в работе, и на среднюю скорость прохождения заявки по процессу, на время нахождения заявки у конкретной группы или сотрудника, и всё это рассмотреть в разбивке по категориям, а ещё для разных приоритетов… Много, очень много появляется точек измерения, и за деревьями не видно леса. Что со всем этим делать?
Ответ, если не углубляться в детали, таков: система KPI должна соответствовать системе целей. А цели должны быть SMART – конкретными, измеримыми, достижимыми, значимыми и своевременными. Соответственно, первый шаг решения задачи – формулирование целей. Например, целей упомянутого выше процесса управления инцидентами. Только затем – придумывание KPI, которые покажут достижение этих целей.
Наблюдение за работой реальных компаний показывает, что осознание того факта, что цели должны быть SMART, к менеджерам приходит через несколько лет после начала работы. При том, что техники формулирования целей и разработки KPI давно известны.

И вновь наши двери открываются для вас: через пятнадцать минут начнётся День открытых дверей посвящённый курсу "Разработчик Java".

Наш преподаватель - Виталий Чибриков, расскажет всё-всё о курсе, ответит на ваши вопросы и, разумеется, разыграет два бесплатных места.

Присоединяйтесь!
https://youtu.be/j866idQ1dQo

#deepitsm #management #otus
Слышали когда-нибудь термин "приоритеты запросов и инцидентов"?
В любой современной компании есть ИТ-отдел. В каждый ИТ-отдел поступают обращения пользователей – иногда им просто нужна помощь, иногда они сообщают, что что-то сломалось (случился инцидент). Поток обращений может быть довольно большим, а ИТ-специалистов, как всегда, не хватает. Очень важно правильно выстраивать поступающие заявки в очередь, чтобы сотрудники ИТ брали в работу сначала те из них, которые наиболее важны, а только затем следующие. При этом хотелось бы, чтобы задачи «не зависали», и даже не очень важные всё равно решались.
Чтобы выстраивать заявки в очередь, обычно используется понятие «приоритет». Чем он выше, тем скорее нужно браться за работу. Предполагается, что у каждого ИТ-специалиста есть очередь задач, и он берёт из этой очереди задачи в порядке убывания приоритета. Всё хорошо в этой схеме, осталось только понять, как определять приоритет для каждой новой пришедшей заявки.
Вариант подхода к решению – посмотреть умные книжки, например, библиотеку ITIL. Там нам сообщат, что при определении приоритета нужно учесть степень влияния (масштаб бедствия) и срочность (как быстро, по мнению пользователя, нужно выполнить данную задачу). Это очень разумная рекомендация. Вот только остаётся неясным как это всё увязать с крайним сроком, который должны быть виден и ИТ-специалисту, и заявителю, и как сделать так, чтобы до заявок низкого приоритета тоже доходили руки. Желательно до того, как расстроенный пользователь нажалуется своему начальнику, который настучит на ИТ-руководителя на очередном совещании при согласовании ИТ-бюджета. То есть – в самый неподходящий момент.
На практике многие компании поступают по такой схеме: степень влияния (определяется при регистрации заявки) + срочность (оценивается со слов заявителя) = приоритет (чем важнее и срочнее, тем выше). Далее смотрим на ИТ-услугу, которая затронута, а точнее – на SLA по этой услуге, откуда берём крайний срок для данного приоритета. Например: затронут только один сотрудник (влияние низкое низкое), срочность – не к спеху (низкая), приоритет получается низкий, для него крайний срок по SLA – 3 рабочих дня. Заявка встаёт в очередь, так как наверняка есть более срочные работы. Но через пару дней до окончания крайнего срока остаётся всего ничего – один рабочий день, несколько часов. В этот момент система автоматизации ИТ сама поднимает приоритет повыше, и заявка становится более важной. ИТ-специалист не забудет её сделать, при том до окончания крайнего срока, обещанного пользователю. Который никогда не меняется, ибо SLA – это наше всё.
Вот так текст хороших книг (ITIL) можно использовать на практике, чтобы сделать работу ИТ более эффективной.

Нас часто спрашивают: "как проходят занятия?" Те, кто заинтересовался курсом, зачастую хотят не просто познакомиться и пообщаться с преподавателем (для этого мы делаем Дни Открытых дверей на курсах), но и "посмотреть преподавателя в действии" - побывать на лекции в роли слушателя и узнать, как преподаватель излагает материал, какая обстановка на лекции, все ли понятно.
Мы решили, что лучше один раз увидеть, чем тысячу раз услышать и подготовили небольшое видео с одного из вебинаров по Java, где Виталий Чибриков рассказывает о SOLID: https://www.youtube.com/watch?v=s0OKV5dyxks
Смотрите, оставляйте ваши комментарии!

В прошлую субботу начала занятия октябрьская группа по Java. Мы были приятно удивлены, что желающих обучаться в этой группе оказалось сильно больше, чем мы ожидали, и нам пришлось досрочно закрыть набор в группу (ведь превышение допустимого количества учеников в группе может негативно повлиять на качество обучения).
Мы считаем не правильным ограничивать людей в их желании получать знания и профессионально расти, поэтому под натиском желающих серьезно изучать Java мы приняли решение о создании внеочередной группу Java с датой старта 11 ноября.
Набор уже открыт: проходите вступительное тестирование, присоединяйтесь к новой группе: https://otus.pw/Ro5xIPjx/

Мы рады объявить о запуске новой группы востребованного и так сильно любимого нашими студентами курса "DevOps практики и инструменты"!
Почему DevOps?
Несколько фактов о курсе Devops в OTUS:
- один из самых любимых нашими студентами курсов! По итогам первого месяца курс покинули всего 2 студента (и то по причине отсутствия времени на обучение). Остальные студенты оставляют позитивные фитбеки о программе и процессе обучения. Им непросто, но интересно!
- преподаватели курса - коллеги из Express 42 - практикующие специалисты и опытные преподаватели. Значит, на курсе будут только прикладные и актуальные знания в доступной форме.
- хорошие DevOps специалисты очень востребованы на рынке: 8 работодателей ждут наших лучших выпускников на собеседования.
А еще на ноябрьский набор нам удалось сохранить стоимость обучения на уровне августа :) Весомый аргумент, чтобы начать обучение уже 14 ноября. Проходите вступительное тестирование и присоединяйтесь к новой группе!
https://otus.pw/679L8BKj/

Друзья, совсем скоро мы проведем дни открытых дверей по курсам Linux и BigData. Регистрируйтесь, будет интересно! Преподаватели расскажут о курсе, ответят на вопросы и, конечно же, проведут розыгрыш бесплатных мест на курсах среди тех, кто успешно прошел вступительное тестирование. Если вы еще не сдавали тест - самое время это сделать! 🚀
https://otus.pw/QfyqsME8/
Ждем вам на днях открытых дверей!

#deepitsm #management #otus #CMDB
Давайте поговорим о базе данных конфигураций (CMDB).
Когда в ИТ ломается что-то серьёзное, мы всегда знаем кто затронут и каковы будут последствия. При повторяющихся больших сбоях у сотрудников ИТ вырабатывается мышечная память – пятая точка не даст забыть прошлый опыт. Здорово, что таких ситуаций не так много, и крупные инциденты не происходят каждый день.
Зато чуть менее серьёзные проблемы возникают постоянно. Даже в среднем ИТ-отделе из 50-100 человек поток инцидентов составляет десятки и сотни в день. При регистрации нового обращения пользователя очень важно знать, что именно сломалось и что ещё затронуто, чтобы оценить масштаб бедствия и спланировать работы по восстановлению. Без этой информации мы можем оценить сообщение «Не могу войти в компьютер» как незначительное, хотя речь про ERP-систему, выгружающую данные в производственную систему, которая остановит отгрузку готовой продукции предприятия, если нужные данные не поступят в нужное время.
Чтобы иметь возможность быстро и точно понять, что случилось и что затронуто, современные ИТ-отделы выстраивают базу данных конфигураций (CMDB). Эта база данных содержит каталог ИТ-услуг, плюс перечень основных ИТ-компонентов (оборудование, ПО, ИТ-системы целиком) и связи между ними. Полезность этой информации невозможно переоценить.
Например, происходит сбой на диске одного из серверов, о чём ИТ узнаёт от системы мониторинга. При регистрации данного инцидента на основе данных CMDB можно узнать, какие ИТ-системы используют данный сервер? Как они связаны между собой? Какие ИТ-услуги затронуты и как? Есть ли резервный сервер в кластере? Исходя из этого можно определить масштаб бедствия, приоритет инцидента, назначить его в правильную группу специалистов, дать им информацию для анализа. То есть – ускорить устранение критичных сбоев. Тогда ИТ-директор будет доволен и наверняка всех похвалит. Ведь ему перед бизнесом краснеть не придётся, а хорошим сотрудникам и премию не жалко выписать.

Мы обновили пак стикеров OTUS coding Owl. Еще больше классных сов!

Начинаем День Открытых дверей курса "Администратор Linux".
Преподаватель курса Дмитрий Молчанов расскажет о программе курса и карьерных перспективах, ответит на вопросы и проведет розыгрыш бесплатных мест среди тех, кто успешно прошел вступительное тестирование.
Присоединяйтесь к трансляции:
https://www.youtube.com/channel/UCetgtvy93o3i3CvyGXKFU3g/live